cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Re : Cayenne Transactions
Date Tue, 13 Sep 2011 19:43:50 GMT

not sure if you subscribed to the list and receiving the traffic from the list or only the
emails cc'd to your address, as there were other replies in this thread. I am cc'ing now,
but you may want to check the archive for the ongoing discussion.

On Sep 13, 2011, at 10:16 PM, stéphane Lestoclet wrote:

> I think that if it comes to choose
> between Spring and Cayenne, Spring will probably win because it's
> really an integration framework and it's widely used in production.

I guess the points made here were not about choosing between Cayenne and Spring. There is
no such choice. They are complimentary, not competing. I am sure there are hundreds of Cayenne
applications built using Spring container. I've done a few myself (although as of lately I
am using other DI containers). IMO the comments here were alluding to the patterns of integration
even though they may have been worded as "no Spring required" :))

> * persistent entities have to inherit from a cayenne object

I'd say this is a nice alternative to runtime proxies. 

> * transactions are made manually and doe not use the standard ones (javax.transaction)

There has to be a mindset shift here.. Cayenne "transactions" are a different beast and Cayenne
apps are therefore often written differently in respect to tx management. They can be "wrapped"
in JTA transactions if desired. Most people don't bother, preferring the smooth ride of an
ObjectContext (and opt for managing multiple in-memory ObjectContexts instead), but I am sure
there are cases when you have no choice. 

I liked the metaphor made previously on this list, about Cayenne being like SVN (or GIT if
you consider nested contexts) - you checkout your local copy of the DB, work with it as long
as you need without holding any open DB resources (like connections) and then commit your
changes when you are ready. 

Even the context rollback, while it implies a tx, is really an in-memory operation of restoring
the objects state. Moreover rollback is not required, as ObjectContext doesn't hold to any
resources. You can just abandon a context and start a new one.


View raw message