Cris,
I really appreciate your detailed feedback once again. Some replies
inline below...
On May 2, 2005, at 5:00 PM, Cris Daniluk wrote:
>> 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.
I will be working to put much of my business methods in the Cayenne
model classes. So in theory it'll be decoupled from the web app with
the exception of the creation of the thread local DataContext and the
commit/rollback.
> 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...
Good points.
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 :)
>> 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 :)
How do you enable auto-rollback? And why is this not approved of?
> 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.
My application is being completely built from scratch - nothing
legacy at all. I sort of wish there was something already there to
work with to get the thing built quicker, but such is life in
academic research projects - breaking new ground.
> 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...
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.
Thanks again for your time and the good insights.
Erik
This archive was generated by hypermail 2.0.0 : Tue May 03 2005 - 08:41:05 EDT