cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: How does optimistic locking works ?
Date Fri, 29 Apr 2016 13:47:32 GMT
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.

mrg


On Thu, Apr 28, 2016 at 10:31 PM, Juan Manuel Diaz Lara <
jmdiazlr@yahoo.com.invalid> 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
> <jmdiazlr@yahoo.com.INVALID> 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
>
>
>

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