Hibernate version:2.1.6

Here's what I'm trying to do : I have a User domain object that has a set of 'Engagement' objects (one to many relationship). The Engagement domain object in turn has a one to many relationship with a Location entity. The Set of Engagements on the User object is mapped to be lazily loaded in the User mapping and the Set of Locations is also mapped to be lazily loaded in the Engagement mapping.

The user domain object needs to be globally accessible in the web app (used by several jsp's.) Additionally I have screens that can add to/alter the associated Engagement and Engagement.Location.

To accomplish this I have a Servlet filter that upon authentication loads the User doamain object based on the username and adds it to the session as an attribute.

I have another Servlet filter configured that implements the OSIV (Spring's OpenSessionInViewFilter). This filter works fine when say, I load an object from my service implementation and then subsequently access an assocaited collection that was mapped lazily loaded.

However if I try to lookup the User object that was previously loaded (in another session) and try to access a lazily loaded collection, I get the LazyInitializationException. I figured that this was because the User object in the session was loaded by another hibernate session so I added code in my filter to call session.lock(user, LockMode.NONE).

Based on the description in HiA $4.2.2 "Updating the persistent state of a detached instance", I expceted the User object now to always be re-attached to the new hibernate session created by the OSIV filter.

This doesn't seem to be working completely. It appears that now I can call user.getEngagements() however on calling engagement.getLocations() I get the LazyInitializationException. So it seems that the reassociation of the user object with the new session is not nested. Can you confirm this?

Also the descption in HiA section 4.2.2 states that "A call to lock() associates the object with the Session without forcing an update". Based on this description, Is my use of session.lock(..) incorrect?

The book mentions this "a way" to reassociate an object with a session, yet in another thead this technique is called the "wrong way". Did I misread or misunderstand something?

http://forum.hibernate.org/viewtopic.php?t=213&highlight=lazyinitializationexception


I do have non elegant workarounds to the problem I'm facing like re-reading the User object in the servlet filter but there must be something I'm doing wrong as I should be able to reassociate an entire object (with nested properties) with a new session.

Thanks,
Sanjiv
[/url]

I'm almost sure that this isn't in the book, but if you can find the two places, I'd mark the last one in the errata. The "a way" is good here, there is no real recommendation we could make, lock() just a simple method that changes the state of an object. It might of course be the "wrong way" if you have modified the detached object in any way.

The book only mentions using lock() as a way to reassociate a detached object to a session, so long as its state hasn't been modified.

I was referring to another post in the Hibernate Users forum http://forum.hibernate.org/viewtopic.php?t=213&highlight=lazyinitializationexception where this was referred to as the "wrong way".



If the state of an object/data representing object hasn't changed, can you confirm that calling session2.lock(obj, LockMode.NONE) using a session different from the one that originally loaded the object is functionally equivalent to loading the object using a session by calling session.load(MyClass.class, id) with respect to lazy loading of collections.

Having called session2.lock(obj, LockMode.NONE) on an object, under what circumstances will I get a LazyInitializationException error trying to access a lazy association?

Thanks,
Sanjiv[/quote]

This is so easy, I can not describe it any simpler. session.lock() changes the state of an object, from detached to persistent (look those two up in chapter 4). When doing this, lock() will not guarantee that any changes you made to the objects state while it was detached will be made persistent as well.

Okay, thanks. The reason I was asking is because I am getting LazyInitializationException despite calling session2.lock(obj, LockMode.NONE) which should not be happening based on your explanation. Will run my app through the debugger to troubleshoot whats happning.

I ran my code through the debugger and found the following.

Consider the following domain model :

Entity A has a one-one relationship with B. B has a 1-to-many relationship with C. (accessors, identity field, hashCode/equals deliberately left out here. for illustration purposes)



I load an instance of A (aInstance) in session1. session1 is closed and aInstance is not detached. I open a new session, session2 and call



The above call to bInstance.getCees() results in LazyInitializationException despite the fact that we made the root object persistent by calling session2.lock(aInstance, LockMode.NONE).


Now if I explicitly lock bInstance, I am able to successfully read the Set of C objects.

ie



runs successfully without any errors. So calling session.lock(..) on a detached object does not completely change its state from detached to persistent. And this is what I asked him my original mail -

Calling session.lock(..) on all nested properties/collections of a detached object is not a clean solution.

So is this behavior of session.lock(..) not completely making a detached objected persistent an expected behavior? If so, whats the reason behind not making the entire relationship persistent?

Thanks,
Sanjiv