cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Manuel Diaz Lara <>
Subject Re: How does optimistic locking works ?
Date Fri, 29 Apr 2016 20:25:20 GMT
Thanks for your reply.... to clarify, my version field is marked as the only field used for
optimistic locking, and the entity was market too for optimistic locking, the problem was
that I was expecting cayenne to manage the version field, but the only thing it does is to
add the condition to the where clause to implement the verification part of the optimistic
locking strategy.
As I wrote in a previous mail, the solution is to increment the version field ourself (from
the app code) just before we commit, and for this there could be several strategies.
 Atte. Juan Manuel Díaz Lara 

    On Friday, April 29, 2016 8:48 AM, Michael Gentry <> wrote:

 Hi Juan,

Typically in Cayenne you wouldn't have a version field.  You'd instead
optimistically lock on "units" and other values.

Assuming you optimistically locked on "units" and using the example code
you gave, you would only get an exception if some other activity changed
the value of "units" in the database:

a) after your initial fetch and before your first commitChanges
b) after your first commitChanges and before your second commitChanges

If you aren't familiar with optimistic locking, in Cayenne Modeler make
sure you have "Optimistic Locking" checked on your StockCurrent ObjEntity
(under the "Entity" tab), then also make sure you have "Used for Locking"
checked (under the "Attributes" tab) for "user" and other attributes.

Cayenne will then verify those checked attributes have not changed when you
do a commitChanges.  You don't need the version field unless you have a
requirement to know how many times something has been updated, but that's
not a very good requirement since you probably really want to know what has
changed instead, which is an entirely different discussion.


On Thu, Apr 28, 2016 at 10:31 PM, Juan Manuel Diaz Lara <> wrote:

> Ok, I was thinking on other frameworks... the simple solution is to
> increment the version field from the app before commitChanges() (anyway the
> commit will only succeed if the orinal value of the version field is equal
> in the db). I made this on a preUpdate lifecycle event to not forget to do
> it and ensure a monotonically increment.
> To anyone maybe interested.
>  Atte. Juan Manuel Díaz Lara
>    On Thursday, April 28, 2016 5:52 PM, Juan Manuel Diaz Lara
> <> wrote:
>  I have this simplified scenario where the second commitChanges fails with
> an optimistic exception:
>        s = CayenneDao.instance.getByPrimaryKey(StockCurrent.class,
> testStockcurrentId);
>        s.setUnits(s.getUnits()+1));
>        context.commitChanges();
>        s.setUnits(s.getUnits()+ 7);
>        context.commitChanges();
>  I have traced the log and I can see that the version field con s is not
> updated after first commit, that is annoying because it break's the second
> commit.
> So the question is: what is the cayenne contract in relation to optimistic
> locking ? what does it do ? only testing when committing ? does not update
> version field nor refresh it from db when commiting ?
> In my db, I have a version field in every table (integer), and a trigger
> that updates it if not done from the app, any way, how can I make this to
> work ?
> Atte. Juan Manuel Díaz Lara

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message