Just do this and it'll fix the "failed to find a snapshot for EO with Global ID" error?
setRetainRegisteredObjects( true ); Bravo! Calven On 2012-06-21, at 3:00 PM, <[email protected]> wrote: > From: Maik Musall <[email protected]> > Subject: Re: failed to find a snapshot for EO with Global ID > Date: 21 June, 2012 5:45:38 AM EDT > To: WebObjects Development <[email protected]> > > > 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
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
