Re: just checking...
Re: just checking...
- Subject: Re: just checking...
- From: OC <email@hidden>
- Date: Tue, 19 Apr 2016 22:43:33 +0200
Chuck,
On 19. 4. 2016, at 22:30, Chuck Hill <email@hidden> wrote:
>> (b) contrariwise, with WOAllowsConcurrentRequestHandling = YES, two R/R loops can be processed at the same time. Which might cause one of them save changes, and in a couple of milliseconds another save its changes based on a different (no more up-to-date) snapshot. In which case optimistic locking would help tremendously, for, well, it would recognise the fact that the snapshot is not up-to-date, and throw instead of blindly overwriting the values.
>
> No. :-) EOF will have merged the changes into the snapshot
But when?
I thought you confirmed my impression that a locked EC does not get the changes, until unlocked.
With concurrent requests, I imagined the order of operations might be
(i) thread A starts R/R and locks ECa
(ii) thread B starts R/R and locks ECb
(iii) thread A saves; change notifications duly noted by ECb, but not processed yet -- ECb still locked
(iv) thread A ends and unlocks ECa, no relevance for us
(v) thread B saves, its WHERE is based on its current snapshot (still same as in (ii)), causing thus an optimistic exception
(vi) thread B ends and unlocks; changes from (iii) get processed now, but too late to prevent the exception in (v)
Well self-evidently I am wrong, but why? At which point does ECb snapshot in this scenario get the ECa changes of (iii)?
Thanks and all the best,
OC
> ... ... ... so the WHERE clause for the second save will match and the save will succeed. You might want an OL exception, but you won’t get one. You need to watch for notifications that EOF sends and use them to track these collisions in your code.
>
>
>> But as always, most probably I am overlooking something of grave importance?
>
> I suspect you might be. You will only get an OL exception if some other process has changed the DB.
>
>
>> [*] unless an EC is manually locked over more R/R loops, which, far as I understand, is a disaster recipe anyway.
>
> It might lead to data freshness issues, but is not necessarily a disaster. I have never done this. Well, not intentionally. ;-)
>
>>
>>>> Actually the hypothesis I tried to formulate was more like “if an application runs one instance and no background tasks, it would work precisely the same -- be it, depending on the policy, wrong or right -- with or without optimistic locking of anything but PKs”.
>>>
>>> Yes, and assuming that no other process will update the database (like you in a SQL tool).
>>
>> Or -- at least I thought so -- assuming no other thread does that before the snapshots can get synchronised. Which -- again, I thought so, probably wrongly -- can easily happen with WOAllowsConcurrentRequestHandling = YES, can't happen at all (well at least, not with standard EC locking policy) with WOAllowsConcurrentRequestHandling = NO.
>
> I am not sure that I am following you here. Changes from another process have nothing to do with the snapshot synchronization.
>
> Chuck
>
>
>>
>> Thanks a lot and all the best,
>> OC
>>
>>>>>> Le 19 avr. 2016 à 09:09, OC <email@hidden> a écrit :
>>>>>>
>>>>>> ... whether I am overlooking something or not.
>>>>>>
>>>>>> I do think that in a single-instance application with WOAllowsConcurrentRequestHandling=NO and without background tasks is locking of any attribute but PK completely superfluous and can be switched off in the model without any adverse effect.
>>>>>>
>>>>>> Am I right? Or do I overlook some disaster scenario?
>>>>>>
>>>>>> Thanks,
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
_______________________________________________
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