Re: failed to find a snapshot for EO with Global ID
Re: failed to find a snapshot for EO with Global ID
- Subject: Re: failed to find a snapshot for EO with Global ID
- From: Maik Musall <email@hidden>
- Date: Thu, 21 Jun 2012 11:45:38 +0200
Hi folks,
Am 16.06.2012 um 02:20 schrieb Ramsey Gurley:
> On Jun 14, 2012, at 3:24 PM, Mike Schrag wrote:
>
>>> So it would seem that the nested ECs are sneaking past this fix and causing havoc. I'm still not sure what about garbage collection triggers this, but I've updated ERXEC so that nested ECs check to see if any of its parents are saving before processing notifications. The test passes with that change in place.
>> The GC + child editing context thing sounds like a problem we ran into a couple years ago ... From my notes:
>>
>> "The essence of the problem is that EO's track retain count as an ivar. This retain count records how many nested ec's contain that EO as well, because they share a snapshot (with refcount = 1). If, however, the parent EO gets garbage collected while the nested EC version of it is still alive, the parent EO's retain count disappears and it throws off the snapshot ref counting.
>>
>> We talked about this and bounced around a couple ideas, but ultimately the one that seemed to have the least side-effects was to track the retain count in the EC rather than the EO. This patch provides an impl of that concept -- retain count is now removed from EO and pushed up into a dictionary in the EC. Now even if the underlying EO gets GC'd, the retain counts won't be lost."
>>
>> ms
>
> Looks like I'll need to investigate this further. My fix doesn't cover all the snapshot issues we are having :-/ After a quiet Thursday, we got a few today. Finding a way to reproduce these errors is difficult.
All right, I had those snapshot exceptions ocurring several times each day in a high-concurrency single-instance app I am maintaining, for years, So I followed this discussion very attentively. I always suspected a bug in EOF, and although I have a few cases of nested EOEditingContexts in my app, I never thought of *that* being the trigger. Instead, I spent whole days searching for anything that might violate one the EOF commandments, but to no avail.
Then, I read this thread, and I included the following call in my own EditingContext subclass' constructors:
setRetainRegisteredObjects( true );
I realize this would strictly only be needed for ECs that have children, but I cannot generelly make that distinction in advance in my case, and as soon as the EC holds EOs, you cannot change that setting any more. So I set this on each and every EC. Turns out, since I don't use session.defaultEditingContext() and all my editingcontexts are short lived (see Chuck's editingcontext talk a few years ago), memory consumption didn't go up that much, like 10 GB previously and 11 GB now on average (machine has 48 GB, so no big deal).
And guess what? The damn' exceptions are GONE! :-)
I have this running since last Monday now, so I'm pretty sure that's a final verdict. So, thanks everyone for this discussion, that was a major breakthrough in app stability for me.
See you in Montréal next week!
--
Maik Musall
email@hidden
tel +49 941 698484-35
fax +49 941 698484-99
mobile +49 171 5576498
===================================
SELBSTDENKER AG - No Vision Too Far
Gesandtenstraße 10
93047 Regensburg
email@hidden
http://www.selbstdenker.ag
Niederlassung: Regensburg
Handelsregister: Regensburg HRB 7860
Vorstand/CEO: Stephan Fürnrohr
Vors. des Aufsichtsrates/Chairman of the board:
Dipl. Betriebswirt (FH) Richard Sibinger
_______________________________________________
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