I am finding that with the Cayenne web app design pattern where the
DataContext has session scope, it is easy to add objects to the
DataContext when building up an object graph for display. If these objects
aren't explicity committed by request it is easy to have them carried
forward in the session DataContext, and have them committed in a
subsequent but unrelated request.
While though careful programming I think I can avoid such issues, but I am
looking for a more easier way of dealing with this. A couple of concepts
1. Using a request scope DataContext
With this I was thinking of a DataContext servlet filter which creates a
new thread local DataContext for each request. If the user does not
explicitly commit changes in the data context, at the end of the request
it will go out of scope and be garbage collected.
Issues with this appoarch could be performance cost of creating a
DataContext for each request (I dont know if this is an issue), and the
loss of the session scope caching benefits the DataContext provides.
2. Using nested DataContext with a request scope
The other idea is to create a nested DataContext from the parent session
DataContext and bind this current thread. I imagine this would give you
the benefits of session scope caching, but still enable you to throw away
uncommitted data context objects at the end of the request. I don't know
if it is any faster to create nested data contexts.
Does anyone have any experience with these patterns or have any comments?
regards Malcolm Edgar
---- This email is intended for the named recipient only. It may contain information which is confidential, commercially sensitive, or copyright. If you are not the intended recipient you must not reproduce or distribute any part of the email, disclose its contents, or take any action in reliance. If you have received this email in error, please contact the sender and delete the message. It is your responsibility to scan this email and any attachments for viruses and other defects. To the extent permitted by law, Zurich and its associates will not be liable for any loss or damage arising in any way from this communication including any file attachments. We may monitor email you send to us, either as a reply to this email or any email you send to us, to confirm our systems are protected and for compliance with company policies. Although we take reasonable precautions to protect the confidentiality of our email systems, we do not warrant the confidentiality or security of email or attachments we receive.
This archive was generated by hypermail 2.0.0 : Sun Mar 26 2006 - 22:02:01 EST