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 <[EMAIL PROTECTED]> 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. > >
