Hi,
On 2016-04-19, 1:03 PM, "OC" <[email protected]> wrote: >On 19. 4. 2016, at 20:06, Chuck Hill <[email protected]> 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 is what I was referring to. The JVM is always MT with at least the GC and finalizer threads running. > >> 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. Yes. > Thus, before a code in a R/R commences, all the ECs (in the same OSC) can be > relied to have synchronised snapshots[*], Yes, with your caveat. >and thus optimistic locking can't help any situation. That is true only if there are not any other instances, applications, processes, etc running that might modify the database. > >(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 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]
