hibernate session-per-request and re-enlistment

[Steve Shucker <ss...@vmsinfo.com>]

I'm revisiting a solution to hibernate entity re-enlistment with a 
session-per-request model.  Back in November, I saw a post from James 
that he was working on a new solution for tapernate.  Is there any 
progress on this that can be shared (either code or notions)?  I'd be 
curious if anyone else has come up with a really robust strategy.

-Steve
> The lazy loading problem can't really be solved in a generalized way.
> But, Tapernate does a lot of work for you.  I wouldn't suggest using
> the property persistence strategies from Tapernate right now.  I'm
> working on a new version that will hopefully be more robust.  The main
> problem that I face is knowing exactly *how* to reattach the detached
> object to the session when a request comes in.  There are a few
> different scenarios and the problem is knowing which one you're in!
> Also, if you use merge or update, then your object's state will be
> persisted at the end of the request (assuming that you leave
> transaction-per-request on).  What if you don't really want the state
> persisted during that request (you're in the middle of a "wizard"
> perhaps)?  I think the way to go is to use the
> session-per-conversation pattern, but I'm trying to come up with a
> good way to specify conversation boundaries.  Also, should we support
> more than one conversation at a time (what if the user clicks to go to
> another part of your webapp from within your wizard)?  If so, how do
> the potentially orphaned conversations get cleaned up?    This is what
> causes me to loose sleep at night (yes, I need a life). :-)
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: hibernate session-per-request and re-enlistment

[Henri Dupre <he...@gmail.com>]

On 1/10/07, Steve Shucker <ss...@vmsinfo.com> wrote:
>
> I'm revisiting a solution to hibernate entity re-enlistment with a
> session-per-request model.  Back in November, I saw a post from James
> that he was working on a new solution for tapernate.  Is there any
> progress on this that can be shared (either code or notions)?  I'd be
> curious if anyone else has come up with a really robust strategy.



Our current solution is the following:
I added a filter in the ASO manager of Tapestry (SessionManager I believe)
so that every ASO that implements a specific interface gets connected to the
current hibernate session when it is accessed first and the other part is
that I "disconnect" every object before storing them back in the session (I
save the pk in the holder... this is transparent). This has been saving a
huge amount of memory.
The holder makes the hibernate sessions invisible, when disconnected the
holder contains only the primary key+class of the object but no hibernate
object.

The current uglyness comes that my current interface is so far not that
clean... In every ASO I use a HibernateHolder wrapper to reference the
entity and each ASO has to specify which objects and childs objects need to
be also connected and disconnected.
It's not the cleanest way but so far has been very robust.

-Steve
> > The lazy loading problem can't really be solved in a generalized way.
> > But, Tapernate does a lot of work for you.  I wouldn't suggest using
> > the property persistence strategies from Tapernate right now.  I'm
> > working on a new version that will hopefully be more robust.  The main
> > problem that I face is knowing exactly *how* to reattach the detached
> > object to the session when a request comes in.  There are a few
> > different scenarios and the problem is knowing which one you're in!
> > Also, if you use merge or update, then your object's state will be
> > persisted at the end of the request (assuming that you leave
> > transaction-per-request on).  What if you don't really want the state
> > persisted during that request (you're in the middle of a "wizard"
> > perhaps)?  I think the way to go is to use the
> > session-per-conversation pattern, but I'm trying to come up with a
> > good way to specify conversation boundaries.  Also, should we support
> > more than one conversation at a time (what if the user clicks to go to
> > another part of your webapp from within your wizard)?  If so, how do
> > the potentially orphaned conversations get cleaned up?    This is what
> > causes me to loose sleep at night (yes, I need a life). :-)
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Henri Dupre
Actualis Center