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: ocs--- via Webobjects-dev <email@hidden>
- Date: Thu, 14 Oct 2021 21:13:41 +0200
Samuel,
thanks for a reply!
> This is probably a bug in the change propagation
Indeed. I am seeking for its source and for a work-around to render the bloody
thing harmless :)
> Do you use EOEditingContext with long life span
I do. As I wrote, mostly (and far as this particular problem goes, exclusively)
I use session default ECs.
> My experience is short life is much better
I do believe a complete re-write of the application could help, either using
transient ECs as you suggest, or going even further and assign each session its
own OSC and sync manually, as Chuck suggested some time ago; but I am afraid I
can't quite afford that at the moment. The application is big and contains lots
of legacy code.
At this moment, I would really appreciate a suggestion why the
merge-upon-unlock might not happen properly. Are there any known scenarios to
trigger that?
So far, I've found only one such a case — if the change notification happens
during a save, pure WO/EOF would simply ignore it (wow!) Nevertheless I am
using (my own subclass of) Wonder ERXEC, and this very problem should be fixed
by the “bugfix from Lenny Marks”, which stores save-time notifications and
re-posts them when save is done. Is there another similar problem perhaps, of
which I do now know?
Thanks and all the best,
OC
> On 12. 10. 2021, at 1:26, Samuel Pelletier <email@hidden> wrote:
>
> 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 <mailto: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
>> <mailto: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