Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Date: Fri, 29 Apr 2016 20:25:20 +0000 (UTC)
From: Juan Manuel Diaz Lara <jmdiazlr@yahoo.com.INVALID>
Reply-To: Juan Manuel Diaz Lara <jmdiazlr@yahoo.com>
To: "user@cayenne.apache.org" <user@cayenne.apache.org>
Message-ID: <142279776.5117643.1461961520933.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
 <CAOy5kzOQ4UT+LmG-r-aWTLdHf0kDeyXbwdBbXhU4DGmxMtCRPQ@mail.gmail.com>
References: 
 <CAOy5kzOQ4UT+LmG-r-aWTLdHf0kDeyXbwdBbXhU4DGmxMtCRPQ@mail.gmail.com>
Subject: Re: How does optimistic locking works ?
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_5117642_1117963259.1461961520929"

------=_Part_5117642_1117963259.1461961520929
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for your reply.... to clarify, my version field is marked as the onl=
y field used for optimistic locking, and the entity was market too for opti=
mistic 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 wh=
ere clause to implement the verification part of the optimistic locking str=
ategy.
As I wrote in a previous mail, the solution is to increment the version fie=
ld ourself (from the app code) just before we commit, and for this there co=
uld be several strategies.
=C2=A0Atte. Juan Manuel D=C3=ADaz Lara=20

    On Friday, April 29, 2016 8:48 AM, Michael Gentry <blacknext@gmail.com>=
 wrote:
=20

 Hi Juan,

Typically in Cayenne you wouldn't have a version field.=C2=A0 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.=C2=A0 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 t=
he
> commit will only succeed if the orinal value of the version field is equa=
l
> in the db). I made this on a preUpdate lifecycle event to not forget to d=
o
> it and ensure a monotonically increment.
> To anyone maybe interested.
>=C2=A0 Atte. Juan Manuel D=C3=ADaz Lara
>
>=C2=A0 =C2=A0 On Thursday, April 28, 2016 5:52 PM, Juan Manuel Diaz Lara
> <jmdiazlr@yahoo.com.INVALID> wrote:
>
>
>=C2=A0 I have this simplified scenario where the second commitChanges fail=
s with
> an optimistic exception:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 s =3D CayenneDao.instance.getByPrimaryKey(Stoc=
kCurrent.class,
> testStockcurrentId);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 s.setUnits(s.getUnits()+1));
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 context.commitChanges();
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 s.setUnits(s.getUnits()+ 7);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 context.commitChanges();
>=C2=A0 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 secon=
d
> commit.
>
> So the question is: what is the cayenne contract in relation to optimisti=
c
> locking ? what does it do ? only testing when committing ? does not updat=
e
> 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=C3=ADaz Lara
>
>
>

  
------=_Part_5117642_1117963259.1461961520929--