Chuck, On 24. 1. 2015, at 0:09, Chuck Hill <ch...@gevityinc.com> wrote: > Short answer: no, you should not be locking the object. I’ve never seen > anyone take out a database lock like this.
OK, I'll try, thanks! > === > EOEditingContext ec=auction.editingContext() > EOObjectStore osc=ec.rootObjectStore() > osc.lock() > > Why are you locking this? Nothing in the code below needs it. Learnt it here: http://terminalapp.net/dr-optimistic-locking/ -- have I misunderstood something of importance? > try { > EOEditingContext tempec=ERXEC.newEditingContext() > tempec.fetchTimestamp=System.currentTimeMillis() > def tempau=auction.localInstanceIn(tempec) > tempec.lockObject(tempau) // * > > Don’t do this. It is not needed. Well, for most people. With you I am not > so sure… :-P Anyway I'll try :) > ... yadda yadda yadda ... > > tempec.saveChanges(); > } catch (exc) { > PRINT_ERROR(exc,"Exception adding price offer FOR prc $poValue CU > $sess.currentUser.login") > ... > } finally { > osc.unlock() > } > === > > Is the // * lock wrong? I've thought if two threads try to work with the same > auction, the latter one would wait in the lock until the former saves. > > The normal way to handle this is just to save and detail with any optimistic > locking conflicts that happen. Thanks a lot, OC _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
