not sure if this is by design or if it is a bug, but i'm 90% sure that this is what is going on. i have two transient objects in memory: A and B, each of which has a one-to-many relationship with a lazy loading collection C (which has been initialized on both instances). the same instance of the class in C is associated to both A and B. now, when i do:

session.lock(A, LockMode.NONE);

i see a bunch of:



you can see that the transient instances in collection C are be cascaded to lock() as well - which is fine. problem is, i now do:

session.lock(B, LockMode.NONE);

and then issue a session.flush(), i get:



is this a bug in the cascading code for lock() calls?

It looks extremely unlike a bug.


It looks like you have two different instances of Category, both with the identifier 115.

I suggest you get out your debugger and test my theory.

I think in Category you have not overridden equals() and hash() to work on the actual ID value. On this basis, if you have two instances in memory, Hibernate can't tell they are really the same entity. This can happen with a number of scenarios. For example, you cache an instance (transient) of Category, then later you load a graph of objects which loads another instance with the same id, then you attach your cached instance to somewhere on the object graph which is subject to cascade saving. When you save the graph, you would get this error. In your case, I think it's even simpler.

The solution is to provide a valid equals() and hash() method. But in that case, keep in mind that you are effectly hosed if you generate IDs of a sequence or other native mechanism, and need this object to be a member of a collection, since you will be chaning the key when the object is already in the collection. Bummer.

I wish Gavin would admit that the only clean way to resolve the last issue is for Hibernate itself to rehash the collections that the object is a member of :-) The only solution I know of without changing hibernate, is to make hash() always return the same value, thereby turning all hashtables into linear lists, but at least not violating Collection invariants.

Regards,
Colin