Re: concurrency and consistency
Re: concurrency and consistency
- Subject: Re: concurrency and consistency
- From: Theodore Petrosky <email@hidden>
- Date: Sat, 28 Feb 2015 09:12:38 -0500
I remembered where the transcripts are:
https://wiki.wocommunity.org/display/WEB/Transcripts
I don’t know if what you are looking for is here, but its worth a look.
On Feb 28, 2015, at 6:36 AM, OC <email@hidden> wrote:
> Well thanks, but -- aren't those information available in a comprehensible format, i.e., as text? It's terribly easy to miss an important thing or two when someone just speaks about them.
>
> Of course I completely appreciate that it's the decision of the one who gives out the information to choose the format, and that I'm to be glad the information is available at all, and freely at that, etc etc etc -- but still the current fashion of giving info in a format of movies instead of PDFs is truly a hell :/
> OC
>
> On 28. 2. 2015, at 12:23, Bogdan Zlatanov <email@hidden> wrote:
>
>> I think you might find this video helpful: http://www.wocommunity.org/podcasts/wowodc/east09/WOWODC09E-EOEnterpriseObjects.mov
>>
>> Regards,
>> Bogdan
>>
>> On 28/02/2015 11:50, OC wrote:
>>> Hello there,
>>>
>>> I might be missing some important point, but I understand that
>>>
>>> (a) editing context, while locked, does not update its registered objects
>>> (b) session's default EC gets automatically locked at the start of the R/R loop, unlocked at the end
>>> (c) the underlying (and shared) snapshots are updated whenever any EC saves to the DB.
>>>
>>> Is it indeed so?
>>>
>>> I, as always, am probably overlooking something of importance, but it seems to me this approach can work reliably with WOAllowsConcurrentRequestHandling=NO only. Correct me please if I am wrong, but it seems to me as soon as I switch WOAllowsConcurrentRequestHandling=YES, without adding some extra tricks/OSC locking/something like that to _each_ saveChanges, the following scenario can always happen:
>>>
>>> (i) request A in thread A starts processing, locks its ECa
>>> (ii) request B in thread B starts processing, locks its ECb
>>>
>>> (iii) request A changes some important value, say, "auction.auctionDidEnd=new NSTimestamp()"
>>> - it changes more things appropriately, e.g., it creates an audit record, etc.
>>> - and it calls ECa.saveChanges() -- all the changes are committed to the database all right, shared shapshots get updated properly
>>>
>>> (iv) request B makes some unimportant change, say, "auction.greeting='hi'"
>>> - and it calls ECb.saveChanges()
>>>
>>> At this moment, ECb compares values in its auction object (which does not know about the (iii) yet, for its ECb is locked and thus does not update) to the snapshot (which, contrariwise, has been updated in (iii) when ECa did save), and based on that generates essentially the following SQL:
>>>
>>> ===
>>> UPDATE auctionTable
>>> SET
>>> greeting='hi', ## (1)
>>> auctionDidEnd=NULL ## (2)
>>> WHERE
>>> auctionDidEnd=<the timestamp of (iii), got from the snapshot> ## (3)
>>> AND greeting=<any sweet previous value>
>>> ===
>>>
>>> (1) is the presumed behaviour, we made the change in (iv). Surprising though is (2), we did not make the change -- but it does happen, for (a) the auction EO in ECb contains NULL for auctionDidEnd (it has not been updated, for the EC is locked), and (b) at the same time, the shared snapshot has been updated by the save at (iii), and contains a non-null timestamp for that attribute -- and therefore EOF will generate the appropriate SET.
>>>
>>> The optimistic locking won't help, for again, the shared shapshot has been updated and contains the timestamp stored at (iii); therefore the WHERE would look like (3) and the COMMIT will happily save the changes.
>>>
>>> Which means the business model got terribly inconsistent: the auction did end at (iii), it was duly audited and perhaps it caused lots of other changes; but in (iv), it has been blindly re-surrected due to (2)!
>>>
>>> Now, of course, it's again a similar case to multi-instanceness: if one writes the application from scratch with concurrency on mind, it's comparatively easy to prevent. Nevertheless, I don't know of you, but with my code it simply is not the case; there is heaps of legacy code, written years ago, when nobody ever considered multi-instanceness or concurrent request handling.
>>>
>>> It sort of seems to me this is a cul-de-sac: without a serious rewrite, there simply is no way at all to use legacy code with concurrent request handling or multi-instance: as soon as that happens, there is _always_ a danger of grave inconsistencies.
>>>
>>> Or am I missing some nice tricks here?
>>>
>>> Thanks a lot for any insight,
>>> 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
_______________________________________________
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