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 <blackn...@gmail.com>
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.
mrg
On Thu, Apr 28, 2016 at 10:31 PM, Juan Manuel Diaz Lara <
jmdia...@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
> <jmdia...@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
>
>
>
