Re: locking with more coordinators causes an exception?
Re: locking with more coordinators causes an exception?
- Subject: Re: locking with more coordinators causes an exception?
- From: OC <email@hidden>
- Date: Sat, 24 Jan 2015 00:20:11 +0100
Chuck,
On 24. 1. 2015, at 0:09, Chuck Hill <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden