proper hibernate object house-keeping in tapestry?

[Pete <pe...@gmx.org>]

Hi folks,

my application uses 'long-living' hibernate objects that are either stored  
in session or application scope or
being persisted using the data squeezer.

So far I digged two approaches for managing hibernate objects in tapestry:

#1: just serialize object [java.io.Serializable] and later on (after  
deserialization) attach it to the hibernate session using e.g.  
session.lock(obj, mode)
#2: store the [primary key + type] instead of the real object and later  
get it back using session.get(type, id)

So far I discovered two problems with #1

example 1:
- user 1 stores object in session
- user 2 deletes it in the meantime
- user 1 tries to reattach from session -> BOOM!!

example 2:
- user 1 displays some master-detail relationshop
- user 2 add a new detail
- user 1 (after reattach) gets the old version without the new detail of  
user 2
(I am not quite sure if this behaviour is by design or by me from improper  
usage of hibernate)

#2 seems to be better fitting but this would require to interfere with all  
data squeezers and persistence managers (and ???)
in tapestry to get a transparent solution without hibernate code  
distributed all over in your pages. Also it's less
performant as for every request a few selects are required (even though  
this might happen inside the second level cache).
And it's contrary to tapestry's philosopy of keeping objects instead of  
id's.

Can somebody give me a reality check on that or tell me if I am missing  
some elegant solution?

Thanks a lot
Pete

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

RE: proper hibernate object house-keeping in tapestry?

[Patrick Casey <pa...@adelphia.net>]

	Well, I don't know if it's elegant or not, but I wrote my own
persistence manager that stores long-transaction objects in the visit
object. Then each page that goes out contains a "persistKey" that I use to
yank the appropriate persistent context out of the visit object just in time
for page processing.

	If you couple that with a long session pattern (attaching and
detatching in either a servlet-filter or in your servlet's doService method,
you can instantiate a Hibernate object and keep using it in its native
session with every subsequent request.

	This approach does have its downsides, of course, like it uses a
chunk of memory and your HttpSession gets largeish, but otherwise it seems
to work better for me than the other approaches.

	--- Pat

> -----Original Message-----
> From: Pete [mailto:pertl@gmx.org]
> Sent: Saturday, September 03, 2005 2:22 AM
> To: tapestry-user@jakarta.apache.org
> Subject: proper hibernate object house-keeping in tapestry?
> 
> Hi folks,
> 
> my application uses 'long-living' hibernate objects that are either stored
> in session or application scope or
> being persisted using the data squeezer.
> 
> So far I digged two approaches for managing hibernate objects in tapestry:
> 
> #1: just serialize object [java.io.Serializable] and later on (after
> deserialization) attach it to the hibernate session using e.g.
> session.lock(obj, mode)
> #2: store the [primary key + type] instead of the real object and later
> get it back using session.get(type, id)
> 
> So far I discovered two problems with #1
> 
> example 1:
> - user 1 stores object in session
> - user 2 deletes it in the meantime
> - user 1 tries to reattach from session -> BOOM!!
> 
> example 2:
> - user 1 displays some master-detail relationshop
> - user 2 add a new detail
> - user 1 (after reattach) gets the old version without the new detail of
> user 2
> (I am not quite sure if this behaviour is by design or by me from improper
> usage of hibernate)
> 
> #2 seems to be better fitting but this would require to interfere with all
> data squeezers and persistence managers (and ???)
> in tapestry to get a transparent solution without hibernate code
> distributed all over in your pages. Also it's less
> performant as for every request a few selects are required (even though
> this might happen inside the second level cache).
> And it's contrary to tapestry's philosopy of keeping objects instead of
> id's.
> 
> Can somebody give me a reality check on that or tell me if I am missing
> some elegant solution?
> 
> Thanks a lot
> Pete
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org




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