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]
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
