Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Optimistic locking
Date: Wed, 11 Apr 2007 10:05:54 +0200
Message-ID: <CAD995CC0E76D543B3F674B630C22DE5F5DBE4@apollo.side.lu>
Thread-Topic: Optimistic locking
thread-index: Acd7hjZumaV1WgjCTbSAIHSjeXxgUAAhE7lwAACXBcAAAJv7wA==
From: "Marc Gabriel-Willem" <marc.gabriel-willem@side-international.com>
To: <user@cayenne.apache.org>

Hi Peter,

I'm surprised too.=20
As described below in the discussion, I'm using a DC per session and =
moreover I'm creating a child DC when the jsp page allowing the end-user =
to modify the DataObject is displayed.=20
So at the end, I'm calling the commitChanges method on the child DC. Is =
it the source of the problem ?

In the application, I'm no dealing with thread. This is the job of the =
application server. I'd like to avoid working with that stuff.

Regarding the getSnapshotVersion, I guess I should not use it for =
optimistic locking check then ?

Thanks,
Marc


-----Original Message-----
From: Peter Schr=F6der [mailto:Peter.Schroeder@freenet-ag.de]=20
Sent: Wednesday, April 11, 2007 9:45 AM
To: user@cayenne.apache.org
Subject: AW: Optimistic locking

hi marc,

if both threads are notified of the update, there should be no need of =
the optimistic locking. you may use javas synchronization instead.
but i am somewhat surprised that two different data-contexts are =
notified of a change of one object.

kind regards,
peter

-----Urspr=FCngliche Nachricht-----
Von: Marc Gabriel-Willem =
[mailto:marc.gabriel-willem@side-international.com]=20
Gesendet: Mittwoch, 11. April 2007 09:34
An: user@cayenne.apache.org
Betreff: RE: Optimistic locking

Thank you for your reply.

For information, I'm working on a JSF web application.=20
I was doing test using two different browsers (Firefox + IE) in order to
avoid session management problem.=20

Your document describes the optimistic locking as a mechanism that
detects update done using an external application (SQL+, etc). For that
situation, regarding the Cayenne log file, I can tell you it is ok, it
works.

My concern was the concurrency management in the same Cayenne
application (for example, 2 users using the same application and
modifying the same DataObject !).

In that situation, Cayenne does not raise error... Is it normal ?=20
Should I use the "snapshot version" data to check if something has
changed since the beginning of the user modification ?

Thank you
Marc


-----Original Message-----
From: Michael Gentry [mailto:blacknext@gmail.com]=20
Sent: Tuesday, April 10, 2007 5:37 PM
To: user@cayenne.apache.org
Subject: Re: Optimistic locking

In a lot of web applications (JSP, Struts, Tapestry, ...) the session is
usually stored as a cookie in the browser, so opening a new browser
window
and re-connecting to the application won't give you a new session and
therefore you'd be connected to the original session (and DataContext --
I'm
assuming you are storing the DC in the session) with the updated values.
Try your test using different concurrent browsers, such as Firefox and
IE/Safari (for example) and see if you get the same results.  I use
optimistic locking on pretty much everything and haven't noticed a
problem.
I wrote this a long time ago, too, which may or may not help:

http://cwiki.apache.org/CAY/optimistic-locking-explained.html

I'll be out-of-touch for most of the rest of the day, but if you still
have
problems, perhaps someone else on the list can help.

Thanks,

/dev/mrg


On 4/10/07, Marc Gabriel-Willem
<marc.gabriel-willem@side-international.com>
wrote:
>
> Hi,
>
>
>
> I have some trouble with the optimistic locking function.
>
> I set the 'optimistic locking' option to an ObjEntity and moreover I
set
> an attribute as "used for locking".
>
>
>
> I'm in a web environment.
>
>
>
> When I do some modification in a DataObject, the 'log' displayed by
> Cayenne displays properly the query using the attribute for locking
> check.
>
> But, when a concurrent client modifies the 'same' DataObject, no error
> is detected ... because the new value for the optimistic check is
used.
>
>
>
> It is important to note that the DataObject is modified by different
> browser (so different session data context) and by different child
data
> context !
>
>
>
> Scenario:
>
>
>
> My original record > attr1=3DMyAttr1, attr2=3D10:15:10
>
> My record modified by client #1> attr1=3DMyAttr2,
> attr2(UseForLock)=3D10:18:15 [ attrSpecifiedInWhereClause: 10:15:10 ]
>
> My record modified by client #2> attr1=3DMyAttr3,
> attr2(UseForLock)=3D10:19:40 [ attrSpecifiedInWhereClause: 10:18:15 ]
>
>
>
> The value of the attribute used for optimistic locking seems to be
> refreshed...
>
>
>
> Thank you,
>
> Marc
>
>