Ryan Wynn wrote: > > The problem was the old/new session as Rich described. Instead of > rerunning the query I just reattached the objects to the new session > with session.lock. > > I opted for this because the table data comes from 1 of 2 queries > depending on user interaction within the page. Instead of trying to > figure out what the user did to generate the table I just reattached the > objects. > > Is the reattach with hibernate session.lock(obj, LockMode.NONE) > expensive? What does it do? > It does what it is said to do, it locks the object to the session, but the thing is, that this only works with lock if the object has not been altered also it seems to fail with lazy at least in your case ;-)...
I am not even sure if you can alter the object afterwards and save it, I remember vaguely that you cannot. Usually if you do not have any lazy loading problems on your hand you can directly save the object to the session. I have to admit, I have to reread the chapter again, because the mechanisms of attaching reattaching etc... are not too well described there, and even after several projects I still am not fully sure how they differ. All I can say is if you need straight write access from an object outside of your session use save update saveOrUpdate or persist and things should work out as expected. This is definitely one of the biggest issue areas in my opinin, where the Hibernate documentation needs more substance and also where the api has to be simplified. The whole lock only if unmodified, and then even it fails if you write etc... stuff is outright confusing.
