Re: DataContext scope in web apps

From: Cris Daniluk (cris.danilu..mail.com)
Date: Mon Mar 27 2006 - 11:22:17 EST

  • Next message: Marie Goutièr: "Re: ProcedureQuery problem"

    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