> One thing I've just implemented, but want to validate with the
> Cayenne community, is that of automatically rolling back when an
> exception is encountered in Tapestry, and also automatically
> committing at the end of the request (end of the service, actually).
> I'm doing this using a Tapestry IMonitor hook. I'm using session-
> based DataContext stuffed into thread local storage via the
> WebApplicationContextProvider listener.
In the current application I am using Cayenne for, I have designed in
such a way that a call from the web layer to the service layer always
invokes an atomic Unit of Work.This allows me to decouple the webapp
from MVC and vice versa. It also works the opposite direction -
keeping the domain free from Cayenne.
Of course, there are external factors in this project that made it
desirable to avoid coupling of the ORM tool and web layer, namely,
distributability. I personally believe you should either keep cohesion
between these types of things to either a maximum (your strategy
above) or a minimum (my strategy). Just food for thought... if you
couple, you limit your distributability and become much more stuck
with Cayenne+Tapestry. This isn't necessarily a bad thing, and with
the new distribution options in 1.2...
> My rationale is that my listener methods are then free to add and
> modify data in the DataContext, but do not have to concern themselves
> with doing a commit - it'll happen automatically, and likewise with
> rollbacks if an exception happens.
>
I currently auto-rollback, much to Andrus' disapproval :)
I am a fan of the pessimistic auto-rollback, particularly because of
the unchecked CayenneRuntimeException. It prevents failure from
cascading through the application.
> Does this approach make sense? Are there caveats I should be
> concerned with?
I have had the need once or twice to complete a single unit of work in
2 Cayenne transactions due to legacy integration problems, usually in
the form of external processing services. These problems may not occur
in your application, but be aware that if they do, you'll wish you had
more control over the transactions. You may want to design yourself an
out in case you need it down the road.
If you don't have the need or desire to have a unit of work span
requests, and none of the potential issues above apply, then I think
you are doing the right thing. I have used a similar technique in some
smaller webapps with no trouble...
Cris
This archive was generated by hypermail 2.0.0 : Mon May 02 2005 - 17:00:43 EDT