Re: Tapestry integration options

From: Cris Daniluk (cris.danilu..mail.com)
Date: Tue May 03 2005 - 09:17:01 EDT

  • Next message: Cris Daniluk: "Re: unit testing Cayenne objects"

    > If I ever needed to use my business model outside of Tapestry, I
    > would need to add a thread local DataContext (which I already do in
    > my unit tests), and add commit/rollback around it. Maybe that'd be
    > when I get serious about doing some AOP :)
    >
    Sounds like Cayenne and AOP were meant to be :)

    > How do you enable auto-rollback? And why is this not approved of?

    I say that more facetiously than anything else. Andrus and I had a
    discussion about auto-rollback sometime ago. As a general rule, a
    failed operation is going to require an in-context response. For
    example, sometimes you send the user to an error page, sometimes you
    ignore the failure (if a pessimistic cache-write fails for example),
    etc. I was looking for a safety net for cases where someone "forgets"
    to explicitly handle failure and react accordingly. Otherwise, a
    failed commit would cascade to the next unit of work and cause it to
    fail...

    The project I was implementing this on was (unfortunately) Struts, so
    I added the rollback to the end of the BaseAction and that was that. I
    was not auto-committing, so a more elegant solution was not required
    :)

    > It sounds tenuous to span unit of work across requests since the
    > committing request may never come. My application would be best
    > served by ensuring things are written to the database as often as
    > possible so that no one loses any work. In fact, I'll likely end up
    > doing some AJAXy stuff that would save in the background even.
    >

    The best example I could give you of a spanning units is a wizard. You
    mentioned you were going to be essentially making your Cayenne objects
    be your domain objects. In that context, it is very easy to
    absent-mindedly have an object change a property in an otherwise
    non-writing operation. If the property is a db attribute, you could
    inadvertently trigger a potentially undesired database operation.

    I also agree, by the way, that its a bad general idea to span like
    that. I'm not worried so much about the commit not coming (that
    problem takes care of itself... ) as I am about the user browsing to
    an entirely function without completing the multi-step process, thus
    leading to all sorts of inconsistency.

    Cris



    This archive was generated by hypermail 2.0.0 : Tue May 03 2005 - 09:17:02 EDT