Re: again, merge on unlock did not happen :/
Re: again, merge on unlock did not happen :/
- Subject: Re: again, merge on unlock did not happen :/
- From: Samuel Pelletier via Webobjects-dev <email@hidden>
- Date: Mon, 11 Oct 2021 19:26:15 -0400
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
> <email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden