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
<[email protected]> 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
