Hi All,

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 
include:

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.

Reply via email to