cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cris Daniluk" <>
Subject Re: DataContext scope in web apps
Date Mon, 27 Mar 2006 16:22:17 GMT
We also do this (automatically via a ServletFilter, interceptor, etc). In
the pre-nested DataContext world, if I have a page that spans multiple
requests, I create a new DataContext that does not automatically rollback
each request, and bind that to the thread, rather than the session default.
A token in the form links the flow to the new DataContext. Then, if the user
somehow gets objects in a bad state and goes on to other parts of the
application, the clean DataContext is used. A wrapper object for the Action
or whatever seemlessly takes care of this when a token is present.

I imagine with nested contexts, I would do something similar - it is even
conceivable to me to do all write operations in a nested DataContext,
regardless of how many requests it may take. I haven't explored the new code
in depth, but such a design should let you delegate the actual db
commit/rollback to a separate processor within your application, opening up
all sorts of interesting possibilities.


On 3/27/06, Bryan Lewis <> wrote:
> Andrus Adamchik wrote:
> > 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.
> We do a similar thing in our Tapestry apps, mimicking what we used to do
> in WebObjects.  Every time a new page is requested -- our base Page
> class provides a getPage(name) method -- we do the rollbackChanges().
> We seldom have workflow that spans more than one page.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message