Isn't that pattern going to break down in a clustered environment
though? I don't believe a Hibernate session will survive being serialized
and shipped to another (different) web server if the HTTPsession gets passed
around.
--- Pat
> -----Original Message-----
> From: Jacob von Eyben [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 19, 2005 7:14 AM
> To: Tapestry users
> Subject: Re: Hibernate + Spring: LazyInitializationException
>
> As he descripes it, there is no reattachment needed at all.
> The session is keept in the HTTPSession throughout the
> application-transaction, so the next request from the user is just working
> on the domain objects already associated with the ongoing hibernate
> session.
>
> /Jacob
>
> > 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]