Hallo, ich hab folgendes Problem, das ich jetzt auf ein minimum runterisoliert habe um es zu besprechen.
Ich habe 2 Tabellen die per N:1 Verknüfung verknüpft sind.
Eine Master Tabelle und eine Slave Tabelle.
Die Master Tabelle ist mit der Slave durch einen Foreign key verknüpft und ein Cascade all gesetzt.
Create geht einwandfrei durch, ein update auch solange es innerhab einer Session passiert.

Ich habe aber folgenden Fall, ich löse den Master Slave von der Session und setze ein Lock auf den Master in einer 2. Session nach einiger Zeit um die gelösten Objekte zu zu binden. Danach update ich die Objekte die mit geänderten Werten, aber nicht geändertem Surrogat gebunden wurden mit einem session.update oder einen session.saveOrUpdate.
Das commit der Transaktion geht sauber durch, es wird kein Fehler geworfen, aber es wird nichts in die Datenbank geschrieben.
Sprich das upgrade der neu gebundenen Objekte verschwindet im Nirvana.



Hibernate version:2.x

Mapping Dokumente:

<class name="Master" table="master">
<id name="id" column="id" type="java.lang.Integer">
<generator class="sequence">
<param name="sequence">master_id_seq</param>
</generator>
</id>

<property name="value" column="value" type="java.lang.String" />

<many-to-one name="slave" column="slave" class="Slave" cascade="all"/>
</class
>

<class name="Slave" table="slave">
<id name="id" column="id" type="java.lang.Integer">
<generator class="sequence">
<param name="sequence">slave_id_seq</param>
</generator>
</id>

<property name="valueslave" column="valueslave" type="java.lang.String" />
</class>


Code der das ganze verursacht:

master-slave wird geladen
... transaktionsende

master.setValue("value3");
master.getSlave().setValueslave("value3");
theMaster = master;
werte ausserhalb der Transaktion gesetzt

neue session neue transation:
Transaction tx = sess.beginTransaction();
sess.lock(theMaster, LockMode.UPGRADE);
sess.update(theMaster);
tx.commit();


Der Code geht ohne Fehler durch, nur es kommt
nix bei der DB an

Name and version of the database you are using:

Das ganze ist reproduzierbar auf MSSQL und auf Postgres,
deshalb schließe ich mal einen Fehler auf DB Ebene aus.

Ok, ich bin jetzt dem Problem etwas tiefer auf die Schliche gekommen.
Es passiert folgendes.
Wenn man ein Objekt lädt es ändert und dann ein update macht so erkennt Hibernate in derselbe Session, dass es geändert wurde und setzt ein update Kommando sauber ab.
Wenn das Objekt nun an die Session gebunden wird, so passiert rein gar nix, kein Update gar nichts.
Hibernate verweigert schlichtweg das update, vermutlich meint Hibernate das Objekt entspricht dem Stand innerhalb der DB, was es nicht tut.
Ist das ein Bug, oder ist irgendein Parameter falsch gesetzt?
Das ganze ist ziemlich Ärgerlich, da ich mir eigentlich sparen wollte Code zu schreiben, der mir die Werte in innerhalb der Transaktion geladene Objekte reinnagelt.

Debug log

Hibernate: select master0_.id as id1_, master0_.value as value0_1_, master0_.slave as slave0_1_, slave1_.id as id0_, slave1_.valueslave as valueslave1_0_ from master master0_ left outer join slave slave1_ on master0_.slave=slave1_.id where master0_.id=?
Hibernate: select id from slave where id =? for update
Hibernate: select id from master where id =? for update

Das ist alles was ich bekomme, wenn mir noch jemand sagen könnte wie ich den Debug Log auf etwas vernünftiges bekomme, dann könnte ich mehr info posten...

Btw. ich habs grad in Hibernate3 probiert, dasselbe Problem.

Hier ist die relevante debug ausgabe:

DEBUG SQL:311 - select master0_.id as id1_, master0_.value as value0_1_, master0_.slave as slave0_1_, slave1_.id as id0_, slave1_.valueslave as valueslave1_0_ from master master0_ left outer join slave slave1_ on master0_.slave=slave1_.id where master0_.id=?
Hibernate: select master0_.id as id1_, master0_.value as value0_1_, master0_.slave as slave0_1_, slave1_.id as id0_, slave1_.valueslave as valueslave1_0_ from master master0_ left outer join slave slave1_ on master0_.slave=slave1_.id where master0_.id=?
01:16:17,774 DEBUG AbstractBatcher:365 - preparing statement
01:16:17,824 DEBUG IntegerType:59 - binding '5' to parameter: 1
01:16:17,934 DEBUG AbstractBatcher:293 - about to open ResultSet (open ResultSets: 0, globally: 0)
01:16:17,944 DEBUG Loader:384 - processing result set
01:16:17,944 DEBUG Loader:389 - result set row: 0
01:16:17,944 DEBUG IntegerType:86 - returning '3' as column: id0_
01:16:17,944 DEBUG Loader:791 - result row: EntityKey[omtest.Slave#3], EntityKey[omtest.Master#5]
01:16:17,954 DEBUG Loader:941 - Initializing object from ResultSet: [omtest.Slave#3]
01:16:17,974 DEBUG BasicEntityPersister:1641 - Hydrating entity: [omtest.Slave#3]
01:16:17,974 DEBUG StringType:86 - returning 'valueslave2' as column: valueslave1_0_
01:16:18,004 DEBUG Loader:941 - Initializing object from ResultSet: [omtest.Master#5]
01:16:18,004 DEBUG BasicEntityPersister:1641 - Hydrating entity: [omtest.Master#5]
01:16:18,004 DEBUG StringType:86 - returning 'booga2' as column: value0_1_
01:16:18,004 DEBUG IntegerType:86 - returning '3' as column: slave0_1_
01:16:18,004 DEBUG Loader:408 - done processing result set (1 rows)
01:16:18,004 DEBUG AbstractBatcher:300 - about to close ResultSet (open ResultSets: 1, globally: 1)
01:16:18,014 DEBUG AbstractBatcher:285 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
01:16:18,014 DEBUG AbstractBatcher:403 - closing statement
01:16:18,034 DEBUG Loader:504 - total objects hydrated: 2
01:16:18,034 DEBUG TwoPhaseLoad:96 - resolving associations for [omtest.Slave#3]
01:16:18,064 DEBUG TwoPhaseLoad:167 - done materializing entity [omtest.Slave#3]
01:16:18,064 DEBUG TwoPhaseLoad:96 - resolving associations for [omtest.Master#5]
01:16:18,064 DEBUG DefaultLoadEventListener:185 - loading entity: [omtest.Slave#3]
01:16:18,064 DEBUG DefaultLoadEventListener:331 - attempting to resolve: [omtest.Slave#3]
01:16:18,084 DEBUG DefaultLoadEventListener:340 - resolved object in session cache: [omtest.Slave#3]
01:16:18,094 DEBUG TwoPhaseLoad:167 - done materializing entity [omtest.Master#5]
01:16:18,094 DEBUG PersistenceContext:789 - initializing non-lazy collections
01:16:18,094 DEBUG Loader:1330 - done entity load
01:16:18,104 DEBUG AbstractFlushingEventListener:52 - flushing session
01:16:18,104 DEBUG AbstractFlushingEventListener:102 - processing flush-time cascades
01:16:18,124 DEBUG Cascades:806 - processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:18,124 DEBUG Cascades:152 - cascading to saveOrUpdate: omtest.Slave
01:16:18,134 DEBUG AbstractSaveEventListener:393 - persistent instance of: omtest.Slave
01:16:18,134 DEBUG DefaultSaveOrUpdateEventListener:103 - ignoring persistent instance
01:16:18,134 DEBUG DefaultSaveOrUpdateEventListener:140 - object already associated with session: [omtest.Slave#3]
01:16:18,134 DEBUG Cascades:831 - done processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:18,134 DEBUG AbstractFlushingEventListener:150 - dirty checking collections
01:16:18,134 DEBUG AbstractFlushingEventListener:167 - Flushing entities and processing referenced collections
01:16:18,165 DEBUG AbstractFlushingEventListener:203 - Processing unreferenced collections
01:16:18,165 DEBUG AbstractFlushingEventListener:217 - Scheduling collection removes/(re)creates/updates
01:16:18,165 DEBUG AbstractFlushingEventListener:79 - Flushed: 0 insertions, 0 updates, 0 deletions to 2 objects
01:16:18,165 DEBUG AbstractFlushingEventListener:85 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
01:16:18,175 DEBUG Printer:83 - listing entities:
01:16:18,175 DEBUG Printer:90 - omtest.Master{value=booga2, slave=omtest.Slave#3, id=5}
01:16:18,175 DEBUG Printer:90 - omtest.Slave{valueslave=valueslave2, id=3}
01:16:18,185 DEBUG AbstractFlushingEventListener:267 - executing flush
01:16:18,185 DEBUG AbstractFlushingEventListener:294 - post flush
01:16:18,185 DEBUG SessionImpl:254 - closing session
01:16:18,185 DEBUG AbstractBatcher:437 - closing JDBC connection (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)
01:16:18,185 DEBUG JDBCContext:221 - after transaction completion
01:16:18,195 DEBUG SessionImpl:369 - after transaction completion
01:16:23,783 DEBUG SessionImpl:237 - opened session at timestamp: 4576905559175168
01:16:23,783 DEBUG JDBCTransaction:46 - begin
01:16:23,783 DEBUG AbstractBatcher:422 - opening JDBC connection
01:16:23,783 DEBUG JDBCTransaction:50 - current autocommit status: true
01:16:23,783 DEBUG JDBCTransaction:52 - disabling autocommit
01:16:23,853 DEBUG Cascades:574 - id unsaved-value strategy NULL
01:16:23,853 DEBUG AbstractReassociateEventListener:44 - reassociating transient instance: [omtest.Slave#3]
01:16:23,883 DEBUG AbstractLockUpgradeEventListener:53 - locking [omtest.Slave#3] in mode: UPGRADE
01:16:23,883 DEBUG BasicEntityPersister:972 - Locking entity: [omtest.Slave#3]
01:16:23,883 DEBUG AbstractBatcher:277 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
01:16:23,883 DEBUG SQL:311 - select id from slave where id =? for update
Hibernate: select id from slave where id =? for update
01:16:23,883 DEBUG AbstractBatcher:365 - preparing statement
01:16:23,883 DEBUG IntegerType:59 - binding '3' to parameter: 1
01:16:23,983 DEBUG AbstractBatcher:285 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
01:16:23,983 DEBUG AbstractBatcher:403 - closing statement
01:16:23,993 DEBUG Cascades:574 - id unsaved-value strategy NULL
01:16:23,993 DEBUG AbstractReassociateEventListener:44 - reassociating transient instance: [omtest.Master#5]
01:16:23,993 DEBUG Cascades:806 - processing cascade ACTION_LOCK for: omtest.Master
01:16:23,993 DEBUG Cascades:88 - cascading to lock: omtest.Slave
01:16:23,993 DEBUG Cascades:831 - done processing cascade ACTION_LOCK for: omtest.Master
01:16:23,993 DEBUG AbstractLockUpgradeEventListener:53 - locking [omtest.Master#5] in mode: UPGRADE
01:16:23,993 DEBUG BasicEntityPersister:972 - Locking entity: [omtest.Master#5]
01:16:23,993 DEBUG AbstractBatcher:277 - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
01:16:24,003 DEBUG SQL:311 - select id from master where id =? for update
Hibernate: select id from master where id =? for update
01:16:24,003 DEBUG AbstractBatcher:365 - preparing statement
01:16:24,003 DEBUG IntegerType:59 - binding '5' to parameter: 1
01:16:24,013 DEBUG AbstractBatcher:285 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
01:16:24,013 DEBUG AbstractBatcher:403 - closing statement
01:16:24,013 DEBUG DefaultSaveOrUpdateEventListener:103 - ignoring persistent instance
01:16:24,013 DEBUG DefaultSaveOrUpdateEventListener:140 - object already associated with session: [omtest.Master#5]
01:16:24,013 DEBUG AbstractFlushingEventListener:52 - flushing session
01:16:24,013 DEBUG AbstractFlushingEventListener:102 - processing flush-time cascades
01:16:24,013 DEBUG Cascades:806 - processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:24,013 DEBUG Cascades:152 - cascading to saveOrUpdate: omtest.Slave
01:16:24,013 DEBUG AbstractSaveEventListener:393 - persistent instance of: omtest.Slave
01:16:24,013 DEBUG DefaultSaveOrUpdateEventListener:103 - ignoring persistent instance
01:16:24,013 DEBUG DefaultSaveOrUpdateEventListener:140 - object already associated with session: [omtest.Slave#3]
01:16:24,013 DEBUG Cascades:831 - done processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:24,023 DEBUG AbstractFlushingEventListener:150 - dirty checking collections
01:16:24,023 DEBUG AbstractFlushingEventListener:167 - Flushing entities and processing referenced collections
01:16:24,023 DEBUG AbstractFlushingEventListener:203 - Processing unreferenced collections
01:16:24,023 DEBUG AbstractFlushingEventListener:217 - Scheduling collection removes/(re)creates/updates
01:16:24,023 DEBUG AbstractFlushingEventListener:79 - Flushed: 0 insertions, 0 updates, 0 deletions to 2 objects
01:16:24,023 DEBUG AbstractFlushingEventListener:85 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
01:16:24,023 DEBUG Printer:83 - listing entities:
01:16:24,023 DEBUG Printer:90 - omtest.Master{value=value3, slave=omtest.Slave#3, id=5}
01:16:24,033 DEBUG Printer:90 - omtest.Slave{valueslave=value3, id=3}
01:16:24,033 DEBUG AbstractFlushingEventListener:267 - executing flush
01:16:24,033 DEBUG AbstractFlushingEventListener:294 - post flush
01:16:24,033 DEBUG JDBCTransaction:83 - commit
01:16:24,033 DEBUG SessionImpl:308 - automatically flushing session
01:16:24,033 DEBUG AbstractFlushingEventListener:52 - flushing session
01:16:24,033 DEBUG AbstractFlushingEventListener:102 - processing flush-time cascades
01:16:24,033 DEBUG Cascades:806 - processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:24,043 DEBUG Cascades:152 - cascading to saveOrUpdate: omtest.Slave
01:16:24,043 DEBUG AbstractSaveEventListener:393 - persistent instance of: omtest.Slave
01:16:24,043 DEBUG DefaultSaveOrUpdateEventListener:103 - ignoring persistent instance
01:16:24,043 DEBUG DefaultSaveOrUpdateEventListener:140 - object already associated with session: [omtest.Slave#3]
01:16:24,043 DEBUG Cascades:831 - done processing cascade ACTION_SAVE_UPDATE for: omtest.Master
01:16:24,043 DEBUG AbstractFlushingEventListener:150 - dirty checking collections
01:16:24,043 DEBUG AbstractFlushingEventListener:167 - Flushing entities and processing referenced collections
01:16:24,043 DEBUG AbstractFlushingEventListener:203 - Processing unreferenced collections
01:16:24,053 DEBUG AbstractFlushingEventListener:217 - Scheduling collection removes/(re)creates/updates
01:16:24,053 DEBUG AbstractFlushingEventListener:79 - Flushed: 0 insertions, 0 updates, 0 deletions to 2 objects
01:16:24,053 DEBUG AbstractFlushingEventListener:85 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
01:16:24,053 DEBUG Printer:83 - listing entities:
01:16:24,053 DEBUG Printer:90 - omtest.Master{value=value3, slave=omtest.Slave#3, id=5}
01:16:24,053 DEBUG Printer:90 - omtest.Slave{valueslave=value3, id=3}
01:16:24,053 DEBUG AbstractFlushingEventListener:267 - executing flush
01:16:24,053 DEBUG AbstractFlushingEventListener:294 - post flush
01:16:24,053 DEBUG JDBCContext:216 - before transaction completion
01:16:24,053 DEBUG SessionImpl:353 - before transaction completion
01:16:24,073 DEBUG JDBCTransaction:96 - committed JDBC Connection
01:16:24,073 DEBUG JDBCContext:221 - after transaction completion
01:16:24,073 DEBUG SessionImpl:369 - after transaction completion
01:16:24,073 DEBUG JDBCTransaction:157 - re-enabling autocommit
01:16:24,073 DEBUG SessionImpl:254 - closing session
01:16:24,073 DEBUG AbstractBatcher:437 - closing JDBC connection (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)
01:16:24,073 DEBUG JDBCContext:221 - after transaction completion
01:16:24,073 DEBUG SessionImpl:369 - after transaction completion

Es scheint zumindest in Hibernate3 zu funktionieren, wenn ich den expliziten Lock weglassen, weiss der Geier wieso.
In Hibernate2 wird sowas meines Wissens nach noch einen massiven Error.

Erstmal ist lock() _und_ saveOrUpdate() sehr ungewoehnlich und normal ein Zeichen dafuer dass der Entwickler noch nicht so ganz weiss was die beiden Sachen machen, naemlich mehr oder weniger das Gleiche. Ansonsten bin ich jetzt zu faul das Log zu lesen und du solltest in der Lage sein selbst rauszufinden ob Hibernate im Log das macht was du haben willst... Das weiss ich naemlich auch nicht so wirklich. Am Besten nochmal die entsprechenden Stellen in der Dokumentation oder in HiA lesen.

Achja, du verwendest lock() und update() einfach ziemlich falsch. Ein Detached Object das modifiziert wurde kann nicht mit lock() verbunden werden, sondern nur mit update() oder saveOrUpdate() (oder merge...). Dann erst upgrade lock machen. Das steht aber in der Doku die du nochmal lesen sollst...

Danke, für die relativ nichtssagende Antwort wieder mal ein Beweis, dass man sich aus deutschen Foren besser fernhalten sollte und gleich auf die US Foren gehen sollte.


Ein simples, ein Lock darf nur ausgeführt werden wenn die Objekte nicht modifiziert sind sonst hauts nicht hin, hätte auch gereicht, nimm session.merge dann gehts anstatt gleich unfreundlich zu werden.

Ich halte hier mal fest was passiert, für den Fall dass jemand in die gleichen Probleme rennt weil er den entsprechenden Passus in der Doku (4-10 Zeilen) übersehen hat.
Wenn man nicht an die Session gebundene Objekte an die Session andocken will und sich sicher ist, dass sie nicht modifiziert sind, dann kann man lock nehmen.
Wenn sie bereits modifiziert sind, so ist bei Hibernate3 (wie es sich bei 2 verhält, hab ich noch nicht überprüft), so kann man update verwenden, wenn die Session noch keine Objekte mit demselben Id hat, ansonsten muss man session.merge verwenden!

Wichtig, ein lock bindet die Objekte an die Datenbank und setzt derzen Zustand auf ist aktuell und nicht geändert!!!! Wenn man nun das Objekt vona aussen geändert hat und dann ein update fährt so, macht Hibernate genau ein oder mehrere select for update oder select je nach Lockstatuts fährt aber kein Update und wirft auch keine Fehlermeldung!!!!

Man kann das im unteren drittel der Debug Meldungen erkennen:
01:16:18,134 DEBUG AbstractFlushingEventListener:167 - Flushing entities and processing referenced collections
01:16:18,165 DEBUG AbstractFlushingEventListener:203 - Processing unreferenced collections
01:16:18,165 DEBUG AbstractFlushingEventListener:217 - Scheduling collection removes/(re)creates/updates
01:16:18,165 DEBUG AbstractFlushingEventListener:79 - Flushed: 0 insertions, 0 updates, 0 deletions to 2 objects
01:16:18,165 DEBUG AbstractFlushingEventListener:85 - Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections
01:16:18,175 DEBUG Printer:83 - listing entities:
01:16:18,175 DEBUG Printer:90 - omtest.Master{value=booga2, slave=omtest.Slave#3, id=5}
01:16:18,175 DEBUG Printer:90 - omtest.Slave{valueslave=valueslave2, id=3}


Ich gebs zu die Sache ist mein Fehler, dass ich den Teil in der Doku obwohl ich sie mittlerweile 4x gelesen hab übersehen hatte, aber ich denke jetzt ist es auch im Forum dokumentiert, für den Fall, dass es mal jemand braucht!

Mal von diesen kleinen Problemen abgesehen, ist Hibernate eine super Sache, falls einer der Entwickler hier mitliest (ich weiss die meisten sind US Amerikaner, die bei JBoss arbeiten), Danke!

Sorry... ich hab grad die Antwort nochmal gelesen, die Info bezüglich lock und update hast Du mir gegeben, manchmal sollte man Nachrichten 2x lesen wenn man nicht ausgeschlafen ist, tut mir leid, dass ich unfreundlich geworden bin..
Etwas zuviel Schlafdefizit, u.A. weil ich gestern nacht stundenlang die Lösung des Problems gesucht habe.
Eine Frage noch, ist Lock da nicht etwas redundant, wenn ein Update und Merge eigentlich alles macht.

Noe, es macht einiges anders. Aber das findest Du auch noch raus, wenn du endlich mal die Doku liest dazu :) Das scheint dir irgendwie nicht zu gefallen...

Ich werds mir heute am Abend nochmal durchlesen sobald ich Zeit hab.

PS: Kleine Bemerkung am Rande, erstmal Danke, dass Du hier sehr gut hilfst, aber ein bissl weniger Aggressivität würde vielleicht einen besseren Eindruck machen ;-)
(ich muss mich da selber auch reinnehmen, siehe obiges Posting ;-) )