cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@zurich.com.au>
Subject DataContext scope in web apps
Date Mon, 27 Mar 2006 02:58:13 GMT

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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message