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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
