Hi Peter, I'm surprised too. 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. 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öder [mailto:[EMAIL PROTECTED] 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üngliche Nachricht----- Von: Marc Gabriel-Willem [mailto:[EMAIL PROTECTED] 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. I was doing test using two different browsers (Firefox + IE) in order to avoid session management problem. 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 ? 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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=MyAttr1, attr2=10:15:10 > > My record modified by client #1> attr1=MyAttr2, > attr2(UseForLock)=10:18:15 [ attrSpecifiedInWhereClause: 10:15:10 ] > > My record modified by client #2> attr1=MyAttr3, > attr2(UseForLock)=10:19:40 [ attrSpecifiedInWhereClause: 10:18:15 ] > > > > The value of the attribute used for optimistic locking seems to be > refreshed... > > > > Thank you, > > Marc > >
