Chuck, On 19. 4. 2016, at 22:30, 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? 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 protected]> 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 protected]) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >>>>>> >>>>>> This email sent to [email protected] >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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/chill%40gevityinc.com >>>> >>>> This email sent to [email protected] >> _______________________________________________ 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]
