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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
