Re: just checking...
Re: just checking...
- Subject: Re: just checking...
- From: OC <email@hidden>
- Date: Tue, 19 Apr 2016 23:01:33 +0200
Chuck,
On 19. 4. 2016, at 22:48, 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?
>
> During save changes.
>
>> I thought you confirmed my impression that a locked EC does not get the changes, until unlocked.
>
> It does not SEE the changes in terms of the data in the EO’s that it holds, but ALL editing contexts in the same OSC SHARE the same (==) snapshot. And that shared snapshot is what is used to form the WHERE clause.
Aha... I see, thanks.
In that case, I believe that with a single-instance application, which is the sole user of its database, there is absolutely no point in optimistic locking anything but PKs. Right?
>> (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
>
> Missing: (iii 2) The shared snapshot held in the EODatabaseContext is updated with the just saved values.
>
>> (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
>
> There is your misunderstanding. The WHERE is based on the shared and now updated snapshot. Which matches the database (unless something else has updated it at this same time) and thus there is not exception.
>
>> (vi) thread B ends and unlocks; changes from (iii) get processed now, but too late to prevent the exception in (v)
Just so as I understand this completely -- these changes, performed at unlock, consist of just copying up the attribute values from the shared snapshot into all the registered EOs in the EC (but for, I presume, updated ones)?
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