Hi OC, This is probably a bug in the change propagation. Do you use EOEditingContext with long life span (in Session for example) or short life one (in component and task) ?
My experience is short life is much better. At least, you are sure your EOs will reflect the latest snapshot when created in a new EOEditingContext. Creating an EO from an EOGlobalID is very fast when the snapshot is in the OSC (using localInstanceOf for example). I hope this may help, Samuel > Le 7 oct. 2021 à 04:02, OCsite via Webobjects-dev > <webobjects-dev@lists.apple.com> a écrit : > > Hi there, > > I am again here with a mysterious bug; something like this happened before > (with slightly different setup), now it happened again. This time the > attributes involved were NSTimestamps; I (might be wrong, but I) believe the > attribute type is irrelevant to the problem and I am re-writing it below with > strings for clarity. Happened under a non-trivial load, nevertheless, > especially during the step (ii) below, nothing of importance happened in any > other thread (one unlocked its EC, none other logged anything at all). Single > OSC, single instance, no background threads (all the things below were normal > R/R workers), nothing fancy at all. > > The problem, cleaned up for clarity, looks like this: > > (i) eoX.foo=="old", eoX.bar=="ok"; two session default ECs -- let's call them > ecC[hanger] and ecO[bserver] -- have eoX in their registeredObjects > > (ii) two intertwined threads do these operations in this order: > - ThrO: ecO.lock > - ThrC: ecC.lock > - ThrC: eoX.foo="new" (in ecC) > - ThrO: ecO changes other EOs which are not important for us; does not touch > eoX at all > - ThrC: ecC.saveChanges (eoX.foo properly saved into DB as "new") > - ThrO: ecO.saveChanges (other EOs properly saved, no change of eoX, which is > OK) > - ThrC: ecC.unlock > - ThrO: ecO.unlock > > (iii) repeatedly happen these operations: > - ecO.lock > - ecO changes other EOs which are not important for us, never touches eoX > - ecO.saveChanges (other EOs properly saved, no change of eoX, which proves > eoX was never in ecO.updatedObjects) > - ecO.unlock > > (iv) after a while, eoX in ecO is used conceptually like this: > - ecO.lock > - if (eoX.foo=="old") eoX.bar="stale" > - ecO.saveChanges (saves into DB eoX.foo as "old" and eoX.bar as "stale") > > Can you see any possible reason why on earth eoX.foo=="new" was not merged > into ecO as a side-effect of its first (or any subsequent) lock in (iii)? Can > you see any reasonable[1] way to prevent this kind of problems in future? > > Alas creating a separate OSC for each session and syncing them manually is > not really an option for me. > > [1] I've considered to check all registeredObjects of any EC in each unlock, > compare their values to the DB snapshot, if different, check whether they > were locally updated in the EC, if not, (log a warning and) fix the local EC > value from the snapshot. Does not seem to me reasonable though for (a) > efficiency -- I fear it would take too much time -- and (b) a danger of > unintended consequences (especially -- not only -- with unlocks during > processing of the ObjectsChangedInStoreNotification I fear all hell would > break loose if I try anything like that). > > Thanks a lot, > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
