Hi Malcolm,
I understand your question is also somewhat related to CAY-483 issue
that you opened recently.
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.
Can you give an example. How can you add a new *persistent* object
that you don't want to commit? Is it only due to a programming error?
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.
That's a possibility. There is very little overhead in new context
creation. There may (or may not) be a performance degradation due to
the loss of DataContext-level caching. This is application dependent.
Context cache saves you from doing extra DB trips for previously
resolved to-one and to-many relationships... also for the cached
queries if you use them.
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.
As you know nested DataContexts is a new feature, so we don't have
any empiric data on its performance (would love to get your
feedback). Performance overhead it adds is due to the fact that
select and commit operations have to travel through an extra
processing point in the stack. I would say it is appropriate for an
editor form that supposedly accesses/modifies no more than a few
[dozens] of objects; and not appropriate for a search page that may
access thousands of objects.
3. Another possibility - if you never ever carry uncommitted state
across requests, you can setup a filter that does
DataContext.rollbackChanges() at the end of the request. This is a
variation of the request-scope context, only preserving caching
benefits.
Andrus
