They should all be back-ended by the same HTTPSession IE's "open in
new window" and firefox's "open in new tab" don't spawn a new HTTPSession in
my experience. So, if I understand this model properly, the Hibernate
Session's lifespan matches that of the underlying HTTPSession. It's created
when the HTTPSession is created, and destroyed when the HTTPSession is
flushed by the server. Between those two points, it gets disconnected at the
end of every HTTP GET or POST, and reconnected at the next one.
--- Pat
> -----Original Message-----
> From: Markus Eberle [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 20, 2005 12:35 AM
> To: Tapestry users
> Subject: Re: Hibernate + Spring: LazyInitializationException
>
> But if i am putting the hibernate-session into the http-session and the
> user
> starts to "click" around in a second window, how do i decide, when to
> close the
> hibernate-session, as suddenly there are two or even more "transactions"
> associated with it?
>
> Zitat von Jacob von Eyben <[EMAIL PROTECTED]>:
>
> > Yes, thats the point of application-transctions. They span over several
> > user requests, hence typically several minutes.
> >
> > Because of the time it can take to complete an application-transaction
> > you have to call session.disconnect() at the end of every HTTPrequest an
> > reconnect upon a new request.
> >
> > This should release the critical resources at the end of every request.
> >
> > When using application-transactions you should also consider when to end
> > the transaction and release the session.
> > suggestions: when the user reaches a certain point in the flow and when
> > the user session is timed out.
> >
> > /Jacob
> >
> > Pablo Ruggia wrote:
> >
> > >But you have to keep open sessions for several minutes !!
> > >
> > >On 5/19/05, Jacob von Eyben <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>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: tapestry-user-
> [EMAIL PROTECTED]
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>---------------------------------------------------------------------
> > >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>>For additional commands, e-mail: tapestry-user-
> [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]
