Just make sure you do not slip into: session-per-user-session or session-per-application
And it looks like session-per-application-transaction model is prone to that 'double submission' problem if WEB-UI does not prevent it (default behavior) --- Patrick Casey <[EMAIL PROTECTED]> wrote: > > For my use cases it end up basically being the > session-per-application-transaction model. I only > use the encapsulated > session for object that are part of a long > transaction, otherwise I use the > much more common session-per-transaction model. > > --- Pat > > > -----Original Message----- > > From: Konstantin Ignatyev > [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 30, 2005 9:44 AM > > To: Tapestry users > > Subject: RE: hibernate + tapestry (again for the > 1,000,000th time) > > > > This approach seems to be discouraged by Hibernate > > team > > > > http://hibernate.org/168.html > > > > > > --- Patrick Casey <[EMAIL PROTECTED]> wrote: > > > > > > > > Yah, it was kind of a eureka moment for me as > well. > > > Before that I'd > > > struggled with a lot of different approaches to > > > keeping the object itself > > > associated with its session for long > transactions. > > > Glueing the two together > > > though seems to have made that whole difficulty > > > moot. > > > > > > --- Pat > > > > > > > -----Original Message----- > > > > From: Peter Ertl [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, September 30, 2005 6:03 AM > > > > To: 'Tapestry users' > > > > Subject: AW: hibernate + tapestry (again for > the > > > 1,000,000th time) > > > > > > > > yes!!!! > > > > > > > > what a wonderful idea to put the session > lifetime > > > inside the DAO itself. > > > > > > > > you made me see the light at the end of the > > > tunnel!! > > > > > > > > thank you so much !! :-)))))) > > > > > > > > Best regards > > > > Peter > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Patrick Casey > [mailto:[EMAIL PROTECTED] > > > > Gesendet: Freitag, 30. September 2005 14:48 > > > > An: 'Tapestry users' > > > > Betreff: RE: hibernate + tapestry (again for > the > > > 1,000,000th time) > > > > > > > > > > > > > > > > I just finished a major refactor to put in > that > > > sort of > > > > functionality and more fine grained > transactions. > > > The approach I took > > > > was to switch over to a DAO pattern and carry > the > > > session along with the > > > > DAO (disconnecting at the end of the > transaction). > > > > > > > > So a typical (long) transaction was: > > > > > > > > GenericDAO g = new GenericDAO("foo"); > > > > g.loadInstance(key); > > > > // render view > > > > g.disconnectSession(); > > > > // return to user > > > > // user pushes save > > > > // fetch g from HTTPSession > > > > g.reconnet() > > > > // rewind > > > > g.doAction(Action.SAVE); > > > > > > > > > > > > Basically each transaction gets its own > private > > > Long session > > > > this way. For non transactional data, I > switched > > > back to a session per > > > > thread pattern which seems to be working for > me. > > > > > > > > --- Pat > > > > > > > > > -----Original Message----- > > > > > From: Pete [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, September 30, 2005 5:05 AM > > > > > To: [email protected] > > > > > Subject: hibernate + tapestry (again for the > > > 1,000,000th time) > > > > > > > > > > I am working on a implementation of > > > > > 'session-per-application-transaction' > > > > > > > > > > described here: > > > http://www.hibernate.org/168.html > > > > > > > > > > Has anybody ever managed _all_ of these with > > > hibernate + tapestry? > > > > > > > > > > - not using object-id's for reference but > object > > > references for the > > > > > business objects (at least within a single > > > application transaction) > > > > > - not needing attach / detach / merge on a > > > regular base to resync > > > > > object instances with the cache > > > > > - not prefetching associations to avoid > > > LazyInitializationException > > > > > - not using silly data transfer objects > > > > > - having application transactions with a > > > lifetime of longer than a > > > > > simple http request > > > > > - having automatic transaction control with > > > commit as a default > > > > > - having custom transaction control in your > > > application (explicit: > > > > > begin / commit / rollback) > > > > > - clearing / closing the session at the end > of > > > the transaction without > > > > > > > > > making long living session state objects > invalid > > > > > > > > > > Maybe I am just asking for too much... > > > > > > > > > > Hibernate and Tapestry are excellent > products > > > (probably the best in > > > > > their > > > > > category) > > > > > > > > > > Just combining them will drive you _really_ > > > insane :-( > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > > > === message truncated === Konstantin Ignatyev PS: If this is a typical day on planet earth, humans will add fifteen million tons of carbon to the atmosphere, destroy 115 square miles of tropical rainforest, create seventy-two miles of desert, eliminate between forty to one hundred species, erode seventy-one million tons of topsoil, add 2,700 tons of CFCs to the stratosphere, and increase their population by 263,000 Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a Strategy for Reforming Universities and Public Schools. New York: State University of New York Press, 1997: (4) (5) (p.206) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
