Re: T5 Hibernate long conversations (session-per-conversation)
Well, we will probably head into clustering some day. What pattern, then, can we use to do optimistic locking without hibernate "long conversations"? I don't think session-per-request can do it. bill On 4/3/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: 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] -- "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]
Re: T5 Hibernate long conversations (session-per-conversation)
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]
T5 Hibernate long conversations (session-per-conversation)
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]
