I use my own implementation of a session-per-conversation strategy.
What I do is I have a conversation manager that stores all
conversations for a user betwee requests. I persist the conversation
ID to the client using an @Persis("client") annotation. I attach the
conversation in the pageValidateListener() creating a new on if there
is no current conversationId. The conversation manager can be
configured with a conversation timeout so that it cleans up any stale
conversations. This allows several concurrent conversations which was
a requirement in my case. The one thing that one has to be careful is
locking access to the session to avoid any issues. Essentially what I
do is that concurrent requests in the same conversation are not
allowed to execute in parallel but rather one request is made to wait
until the other finishes so that there is no concurrent access to the
session. I had briefly looked at Seam before finding tapestry and
deciding I liked tapestry much better. However, I really liked the
conversation concept found in seam and I based some of my ideas on it
(although I haven't looked at Seam in a while now so I'm not sure how
it's implemented there). It would be really nice to make a
conversation mechanism allowing multiple concurrent conversations and
well defined start/end points natively in tapestry.
On 11/4/06, James Carman <[EMAIL PROTECTED]> wrote:
Bill,
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). :-)
On 11/3/06, Bill Holloway <[EMAIL PROTECTED]> wrote:
> I've seen recently some criticism of Tapestry in terms of using
> Hibernate. Problems with lazy loading. I know Tapernate is out
> there, but the docs are pretty thin. I'm using the threadLocal
> version of the much-documented HibernateUtil in a DAO layer. Going
> well. What will Tapernate actually do for me? Does it really solve
> the lazy-loading problem? Are there decent docs?
>
> I would HATE to have to abandon tapestry to work around performance
> problems falling out of non-lazy-loading.
>
> Thanks,
> Bill
>
> ---------------------------------------------------------------------
> 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]
