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
This archive was generated by hypermail 2.0.0 : Mon Mar 27 2006 - 01:33:06 EST