Chuck, On 19. 4. 2016, at 20:06, Chuck Hill <ch...@gevityinc.com> wrote:
>>> ... WOAllowsConcurrentRequestHandling=NO or YES does not have impact on >>> this subject, only the number of live ObjectStoreCoordinator in the app >>> matter. >>> >>> If you do nat have any external access to the database and a single OSC, >>> you are OK. Changes are propagated to others EOEditingContext under the >>> same OSC during saveChanges, this is the magic part of EOF. >> >> Do please correct me if I am wrong, but I believe this does not happen >> during saveChanges, but at the end of the R/R loop (or, more precisely, when >> ECs are unlocked, which normally is at the end of the loop). > > Well, it depends. The changes are propagated to all other ECs in the same > OSC during save changes. If the EC is not locked, they are processed > immediately. If the EC is locked, they are queued for later processing. For > ECs associated with this session, that should happen at then of the RR loop. > For ECs in other sessions (assuming you are running multi-threaded) I am not sure what “run multi-threaded” here means: far as I can say, Java can't reasonably run single-threaded, but the point of question here is WOAllowsConcurrentRequestHandling, is it not? > that will happen as they are fully unlocked or otherwise need to process > these notifications. > >> Which is why WOAllowsConcurrentRequestHandling has a terrible impact on that. > > I don’t see why it would. Correct me please if I am wrong, but so far I thought that (a) with WOAllowsConcurrentRequestHandling = NO (Java is still multi-threaded, but) all the R/R loops are served sequentially. Thus, before a code in a R/R commences, all the ECs (in the same OSC) can be relied to have synchronised snapshots[*], and thus optimistic locking can't help any situation. (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. But as always, most probably I am overlooking something of grave importance? [*] unless an EC is manually locked over more R/R loops, which, far as I understand, is a disaster recipe anyway. >> 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. Thanks a lot and all the best, OC >>>> Le 19 avr. 2016 à 09:09, OC <o...@ocs.cz> 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 (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >>>> >>>> This email sent to sam...@samkar.com >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com >> >> This email sent to ch...@gevityinc.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
