On 2016-04-19, 2:01 PM, "OC" <[email protected]> wrote:
>Chuck,
>
>On 19. 4. 2016, at 22:48, Chuck Hill <[email protected]> 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?
Yes. Locking anything else is only needed if there will be contention for
updates.
>>> (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)?
Merge or rebase is a more accurate term than copy. There is a EC delegate that
can fine tune how this happens. Generally it updated unchanged values and
retains changed ones.
Chuck
>
>Thanks a lot!
>OC
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
