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.

Reply via email to