Michael Sims wrote: > > I don't mean to speak for Norman, but the point of this thread has been > that > detached objects are not thread safe, so if you are going to store them in > the > HttpSession, you have to serialize access to it in order to avoid > potentially trying > to re-attach the same object to two different Sessions. Norman's approach > avoids > this problem and doesn't require any mutexes or locks... >
Unless I am mistaken, which happens all the time, but it appears that the crux of his "thread safety" is, 1) storing detached instances on the client side -- I am assuming that "persists in the client page" is a reference to the ClientPropertyPersistenceStrategy -- 2) creating new hibernate sessions per page request and 3) closing the hibernate session as soon the the page is done processing the request. Norman Franke wrote: > > My application only uses detached objects that it persists in the client > page for change detection (to determine if the record they were editing > changed while they were editing, which I flag as an > error.) > > . . . > > The first call to getSession() creates a HIbernate session, which is > closed when the page is done > rendering. > Since the detached object appears to be persisted on the client side, the hibernate sessions only exist for the rendering of a single page and the session is closed when the page is done processing, it appears as if the detached object should be isolated to a single hibernate session at a time. If that is true, I was interested in his method/motivation for optimistic locking and cloning the detached object graphs for update. If it isn't, how? Norman Franke wrote: > > my DAO has an "assertUnchanged" method that throws an exception if the two > objects differ, e.g. my detached object and the one read from the > database. In this case, I tell the user that someone else changed their > record and their changes have been lost. > I was interested in knowing more about the implementation of "assertUnchanged" - for all I know his entities could have mapped version attributes and "assertUnchanged" could be calling hibernateSession.lock(detachedInstance, LockMode.READ). If it isn't, I just want to know why. The question about cloning is along similar lines. Carlos -- View this message in context: http://www.nabble.com/Using-Hibernate-detached-objects-in-Tapestry-%28thread-safety-question%29-tf3930468.html#a11202178 Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
