My problem with session-per-conversation is that its totally
incompatible with clustering, since the objects in the detached
session are not propogated to other servers.
That being said; yes some kind of mechanism (as service, an ASO) to
hold onto the sessions between requests, to support detach and
reattach, etc. The tiny bit of work I've done on tapestry-hibernate
(for T5) doesn't support this concept, but it can grow to encompass
it.
On 4/3/07, Bill Holloway <[EMAIL PROTECTED]> wrote:
Has anyone implemented session-per-conversation (my preferred way to
handle optimistic locking) in T5? Right now, tapestry-hibernate
implements session-per-request.
I'm thinking an application state object is a good place to start here
with methods like startConversation() and endConversation() with
hibernate sessions managed by this service.
Any thoughts?
Bill
--
"The future is here. It's just not evenly distributed yet."
-- Traditional
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
