You don't have a 1:1 relationship between Hibernate Sessions and
Database connections. What you do is:
In your servlet's doService() routine you pluck the Hibernate
Session out of the HTTPSession. You then *connect* the Hibernate Session via
Session.reconnect() to associate it with a pooled connection.
After your transaction is done, during your cleanup, you
*disconnect* the session via Session.disconnect() and then stash it
(disconnected) into your HTTP Session.
Net effect is you burn no more Connections than you do with a
session per thread or some other pattern.
--- Pat
> -----Original Message-----
> From: Pete [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 22, 2005 2:40 PM
> To: Tapestry users
> Subject: Re: Another Stupid Hibernate Question (TP4)
>
> the third solution sounds pretty nice...
>
> however, probably only for intranet application with medium visitors
>
> The "session-per-(http)-session" seems dangerous (imho) on a site with
> a high number of page visits. my-sql for example has a maximum number of
> 4000 sessions in parallel (more or less). if each http-session had a
> timeout of say
> 30 minutes, therefore holding the database session for 30 minutes, I could
> imagine
> reaching that connection count limit in a cluster running multiple
> applications relatively easy.
>
> also denial-of-service-attacks are pretty easy to imagine if somebody
> knows of that
> technical implementation detail. you could easily exhaust a database
> system by opening plenty of
> sessions.
>
> however the idea of never attaching/detaching is very sexy :-)
>
> the main problems I encounter with hibernate are:
>
> - editing form content with master-detail data over multiple page requests
> without saving it instantly, but only sometime after several requests.
> this gives me dirty collections
> not being attachable if I use attach/detach. if I use business keys and
> restore the persistent
> objects I have to explicitly save the (partially transient) detail objects
> in a collection and
> selectively reload them to attach them (lock will often give me duplicate
> object exceptions).
> otherwise all transient changes are lost on reload. and if I don't reload
> the object will lack
> a session and I get LazyInitializationExceptions -- aaarrrgggg!
>
> - acceptable performance in a cluster: no megabytes to synchronize in the
> session
> like in attach/detach if you have a large graph of objects
>
> currently I am using a combination of a data squeezer and a persistence
> interceptor
> for persistent properties to transparently work with entities that are
> restored using the
> business key over several request (if somebody is interested I could post
> these).
> however I feel that reloading every request (even though 2-level cache is
> used) is not
> the way hibernate is meant to be.
>
> so attach/detach seems non practicable for clusters
> reload per sessions seems cumbersome and limited
> session-per-application seems dangerous and causes problems with invalid
> form submits (validation)
>
> Over all every solution seems to lack in some way or another.
>
> Could you show me the way to the light ?
>
> thanks
> Peter
>
>
>
> On Thu, 22 Sep 2005 21:42:39 +0200, Patrick Casey <[EMAIL PROTECTED]>
> wrote:
>
> >
> > Please see comments below.
> >
> >> -----Original Message-----
> >> From: Henri Dupre [mailto:[EMAIL PROTECTED]
> >> Sent: Thursday, September 22, 2005 12:34 PM
> >> To: Tapestry users
> >> Subject: Re: Another Stupid Hibernate Question (TP4)
> >>
> >> On 9/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> >> >
> >> > There's a third approach you should definitely consider:
> >> >
> >> > Never detatch your persistent objects and use a long session.
> >> It'll
> >> > prevent all those nasty dirty collection, uninitialized collection,
> >> and
> >> lazy
> >> > initialization problems.
> >>
> >> That's exactly what I am considering. Also this is the approach that
> >> Seam is taking (the new JBoss framework sounds to me like a
> >> Spring+hacks for JSF) .
> >> Are there any troubles by storing a Hibernate Session in a Visit?
> >
> > I dunno. I'm pretty old school so I just store it directly in the
> > HttpSession. I can't see why using the visit wouldn't work as well.
> >>
> >> >
> >> > The downside is that every time a page submits, it writes
> >> "live"
> >> > into your persistent object which will write through the next time
> the
> >> > session flushes so you have to be careful about that.
> >>
> >> I don't see any downside here, wouldn't the same occur with a notbound
> >> exception in a per-session model?
> >
> > I don't think so. In a per-session model you can do a
> > fetch->detach->validate->merge pattern which means that your writes
> don't
> > persist if you fail validation. With the long-session model you can't do
> > that detach step (or you are no longer in session) so you end up writing
> > direct into the persistent entity.
> >
> >>
> >> > Also, make sure you use temp sessions for large queries so as
> >> not to
> >> > pollute your "long" session with lots of persistent objects it
> doesn't
> >> > really need.
> >>
> >> I guess that a downside is that the sessions get very large and suck
> >> memory?
> >> And so ideally I guess there should be 2 hibernate sessions:
> >> one for the "conversation" (accross several pages), and another one
> >> for short lived objects (per page session)?
> >
> > That'd be one approach (keeping two session). I usually just spawn
> > temp session though so I just use one session and then hijack its
> > connection
> > when I need a new one with:
> >
> > Session temp =
> >
> HibHelper.getSessionFactory().openSession(HibHelper.getSession().connectio
> n(
> > ));
> >
> > // fill temp session with gobs of stuff
> > Temp.close();
> > // temp session is now gone but parent long session lives on
> >
> >
> >>
> >> Thanks,
> >>
> >> Henri.
> >>
> >> ---------------------------------------------------------------------
> >> 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]
