I have instances of classes A and C that both reference the same persistent entity, an instance of class B. A happens to hold a collection of instances of class C (lazily loaded). The instance of class A gets loaded along with its reference to the instance of class B in one session and returned to a web-tier client for manipulation. Subsequently, the application decides that it wants to load the collection of instances of class C owned by the instance of class A. In the ejb-tier, in order to make the instance of class A's collection of instances of class C available, I get the current session, lock the instance of class A, then call Hibernate.initialize on the collection of instances of class C owned by the instance of class A. When the session is closed I get an exception:
Caused by: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session
The offending object is an instance of class B, the one referenced by the instance of class A and the only instance of class C in A's collection of C instances.
I'm surprised that this is happening. I would have thought that somehow Hibernate would understand that these two references are to the same object and that I would not have references to two different instances, but two references to the same instance. I thought that this would happen since I have associated the first instance with the session and asked Hibernate to load the object that also has a reference to that same object.
Can anyone give me an idea of how I might get around this problem?

I found that it works if I update the instance of A before initializing the collection of instances of C, but I don't understand why lock(xxx, LockMode.NONE) doesn't have a similar affect. I know I haven't made any changes to the state of A that need to be persisted, so it seems a waste to have to execute an update to the dbms.