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().connection(
));
// 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]
