I had originally discounted using the long-session approach because I remember reading about a few potential problems, particularly with transaction management and exception recovery. This article: http://www.hibernate.org/168.html briefly describes both patterns, namely "session-per-request-with-detached-objects" and "session-per-application-transaction".
I can see that using this model could be potentially simpler, and it's good to hear that you have had some success using it. Copying directly from that discussion, here are the points which discouraged me from using this approach: ... Some problems you'll face if you use the same Session for multiple application transactions, especially if you use the session-per-application antipattern. A session is not thread-safe. Things which are supposed to work concurrently, like HTTP requests, session beans, or swing workers, will cause race conditions. If you keep your Hibernate Session in your Http Session, you should consider synchronizing access to your Http Session. Otherwise, a user that clicks reload fast enough may use the same Session in two concurrently running threads. A HibernateException means your have to rollback your transaction and close the Session. If your Session is coupled to the application; you have to stop the application. Rolling back the database transaction doesn't put your business objects back into the state they were at the start of the transaction. This means the database state and the business objects do get out of sync. Usually this is not a problem, because exceptions are not recoverable and you have to start over after rollback anyway. The Session caches every object that is in persistent state (watched and checked for dirty state by Hibernate). This means it grows endlessly until you get an OutOfMemoryException, if you keep it open for a long time or simply load too much data. One solution for this is to call clear() and evict() to manage the Session cache, but you most likely should consider a Stored Procedure if you need mass data operations. ... This article seems to be fairly old, and maybe some of the issues here have been addressed in Hibernate 3. It would be nice to have an update. Shawn Quoting Schulte Marcus <[EMAIL PROTECTED]>: > I never detach the object from the session - so the sequence is like > this > (starting with a fresh session): > > 1. Request: -make new Hibernate session > -get all X from Database, > -render list of X > -disconnect hib-session from DB and store it in > http-Session > (X's are NOT detached here). > > 2. Request - lookup user's http session, get his hib-session > - reconnect hib-session to Datasource > - load collection X.allMyYs for some X lazily (no > Problem, > the X's are still attached) > - render allMyYs > - as 1. Request > > For me, I *really* started to enjoy Hibernate only after I switching > to the > long session pattern. > > Marcus > > > > -----Original Message----- > > From: Pablo Ruggia [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 19, 2005 2:25 PM > > To: Tapestry users > > Subject: Re: Hibernate + Spring: LazyInitializationException > > > > > > And what happens if you need to access a Collection in a second > > request from user. How it works if you do not reattach the object > ? > > > > On 5/19/05, Schulte Marcus <[EMAIL PROTECTED]> wrote: > > > I'm using the long session pattern put forward in HIA by > > Bauer&King. This > > > works very well - no LazyInitializationException nor > > > NonUniqueObjectExceptions when re-attaching objects. In fact, no > > > re-attaching at all. > > > The recipe is: > > > 1. ServletFilter to manage mapping of Http-Sessions to > > Hibernate-Sessions > > > and putting the latter in a convenient ThreadLocal > > > 2. An IActionListener-Wrapper to commit/rollback as desired > > > 3. Not forgetting to close your Session and throw away > > your persistent > > > objects at an appropriate point (typically, this is "user choses > new > > > working-set" or somethin like that) > > > Only "drawback" - the pattern is not supported by any > > IoC-Containers out of > > > the box - at least by none I know of. > > > If anybody is interested I could post some code ... > > > > > > Marcus > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
