Hi,

Hibernate version: 3.1.3

I'm very supprised. If LazySource contains a set of other entities, the following code



produces the exception
org.hibernate.HibernateException: reassociated object has dirty collection reference
at org.hibernate.event.def.OnLockVisitor.processCollection(OnLockVisitor.java:59)
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:101)
...

As reason I found that after clear session the persistent context is proper cleared, but the session located in the cleared collection is not. Shouldn't session.clear() also do sth. like persistentCollection.removeSession(..) forall collections contained in the session?

If you use the same session for lock'ing the object you will get this error. Try to lock in another session and you wont see the exception.

Yes your right, but I want to stay in the same transaction, so I've to reconnect the same session, right?

Would you agree that the behaviour described above is suprising?


Kind regards
Michael

Is there any specific reason that you have to clear from session and maintain the same transaction?

Yes there is a reason. I want to minimize outside dependencies to hibernate.
An example for such a dependency is:

1. (business layer) begin transaction
2. (persistence layer) read an object A with session.get()
3. (business layer) do things, e.g. clone A towards A' (same id as A)
4. (persistence layer) store objects e.g. A'
5. (business layer) commit transaction

If I detach object A with session.clear() after step 2.) there are no limitations in reassociating A' aggain. If I can't use session.clear() I've to debug the whole business layer for this kind of errors. I think, that's very hard work.


Kind regards,
Michael

To be honest I am confused as how the session is being managed.
In your scenario, I guess you can use session.merge( objectWithCollections ) - dont know if its efficient.

The session is managed with hibernate.current_session_context_class/HibernateUtil pattern, as described in http://www.hibernate.org/42.html. In Step 1.) I start a new session / transaction an in Step 5.) transaction is commited an session closed.

Yes merge is some kind of workaround. But the question is: Why produces lock an exception after session.clear()?
Notabene, the locked object wasn't changed after session.get().

Kind regards,
Michael

I don't think you can unlock an object that is not on the first-level cache anymore. Notice the message: reassociated object has dirty collection reference.

Either this lock operation is superfluous (because clear() already unlocked all the objects), or you should do it before clearing the cache.

It is very possible that, since you cleared the cache, the call to lock() reassociates it. Even though the lock mode is NONE.