I will simplify my previous question. I have a case where I have two objects, one is attached and one is detached, both are referenced in an object graph. Both are equals() but they are not ==. In the hibernate documentation in chapter 11.1.3 it states that if the two objects are equals() then they will be treated the same. However it seems that this is not the case. I am received the dreaded 'a different object with the same identifier value was already associated with the session' exception.

I have even checked that equals is not being called by putting logging in the equals methods of the classes being persisted - the equals() methods are not being called. I know that I could go through and manually copy all the references for these objects to be the same but I have a complicated object graph with many references across many objects - this would make for nasty code and be very time consuming.

To me it seems that hibernate is not acting as it says in the documentation - I would appreciate it if someone could provide some clues to lead me out of the mire.

Regards,

Neil

Yes it does. The documentation says that in a given session JVM identity (==) is guaranteed by Hibernate, but if you mix objects from different session you need to use equals().



I can't find anything that supports this statement when the objects comes from different sessions.

Have you tried using Session.merge()?

Hello,

I've tried using merge but that does not work, I set cascade to include merge on all relationships but the same thing happens. The crucial sentence in the documentation I think is the following one:
--
business object in two different sessions, the two instances will actually be "different" (JVM identity). Conflicts are resolved using (automatic versioning) at flush/commit time, using an optimistic approach.
--
If I can decode what that means then I think I am on the way to solving my problem. The specific problem is that I have an object graph which contains two copies of the same object that are equal but not == (one filled in on the request and one filled in on the response) and this happens in a lot of places.

This happens a fair bit in my team but generally we have hacking around it by manually coping the references - in this case that would be tricky. Just to be clear on the merge - I will double check everything!

This means that the two objects live in two different sessions and they continue to do so.
If BOTH sessions are comitted then conflicts will be resolved with the help of optimistic locking. Optimistic locking requires that you have a version or timestamp property on your entity. If only one of the objects have been modified everything will be ok and both transactions will succeed (with or without optimistic locking). But if both objects has been modified, the second transaction will:

* Fail with a StaleStateException (if optimistic locking is used)
* Overwrite the changes from the first transaction (if optimistic locking is not used)