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.
Cris
On 3/27/06, Bryan Lewis <brya..aine.rr.com> 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.
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 27 2006 - 11:22:40 EST