Hi and thanks for your detailed answer,
just adding my 2ct :
we've got the same errors in the same environment : deep nested editing
context's. (WO 5.3 + Wonder, don't know about 5.4 though)
At that time, the only workarounds we found were :
- when possible, reducing the level of nested (basically only 1 level of nested
ec)
- or as someone mentioned, using parentEC.setRetainsRegisteredObjects(true)
Cheers,
Alex
Le 3 nov. 2010 à 11:39, Sobanski, Jedrzej a écrit :
> Hi,
>
> After spending quite some time on similar problem I would like to share what
> solved the issue in my case.
>
> ENVIRONMENT
> We had a scenario that ALWAYS caused this to happen. There was too much code
> to make it a separate app, but basically it involved inserting, updating and
> deleting objects, with nesting editing contexts up to 2 levels deep several
> times. Whenever we saved changes in nested editing context, it was no longer
> used and simply abandoned (so never saved changes twice on the same EC).
> Application never crashed on saving changes in nested editing context, but
> did always crash at the end of the test scenario when saving changes in the
> root editing context. I tried to reduce our test scenario, but removing some
> of test steps did only cause the issue to happen more rarely rather than
> always. Test involved just bunch of operations and none of them appeared to
> be crucial or unneeded. Root EC was locked in Session#awake() and unlocked in
> Session#sleep(). It didn't matter whether we were using EODatabaseContext or
> ERXDatabaseContext. Code (probably) didn't violate any of EOF commandments or
> at least I wasn't able to find such (or I fixed them where I'd found such
> violations).
>
> The only EO related properties set are
> er.extensions.ERXEnterpriseObject.updateInverseRelationships=false
> er.extensions.ERXEnterpriseObject.applyRestrictingQualifierOnInsert=true
> I'm not sure if those had any importance for this issue.
>
> EXCEPTIONS
> Problem was revealing itself in two ways:
> a) java.lang.IllegalStateException: rowDiffsForAttributes: snapshot in
> com.webobjects.eoaccess.EODatabaseOperation {_dbSnapshot = {}; ....
> b) ObjectNotAvailableException: No ... found with globalID: ...
>
> In both cases cause was the same - _dbSnapshot was null at some point, while
> it shouldn't. Sometimes, depending on the order of operations happening when
> saving changes, EOEditingContext did change that _dbSnapshot value from null
> to an empty array and that's why we were getting sometimes two different
> exceptions for the same scenario which implies that both errors have common
> cause.
>
> WHAT SOLVED IT IN MY CASE
> I spent quite some time on it trying to find the root cause, though none of
> advices I was able to find, did help. Eventually disposing each nested
> editing context after saving its changes (in my case they were not used
> anymore) solved this issue.
>
> --
> Regards,
> Jedrzej Sobanski
>
> On Apr 1, 2010, at 7:03 PM, Chuck Hill wrote:
>
>
> On Apr 1, 2010, at 5:24 AM, Marc Guenther wrote:
>
> Hi all,
>
> I spent quite some time now on this problem. I found a way to
> reproduce it, still I have no idea what to do about it.
>
> Can you share what that is?
>
>
> What I don't understand, if this is a known bug, and people are
> actually experiencing it, why have I never heard about it, and why
> is there no fix? This seems to be a major problem.
>
> I also found, that this also happens on WO5.2.3, which makes it even
> worse. I wonder why it has never bitten us before. Or maybe it has,
> but now some customer discovered some peculiar workflow which
> triggers this more often than usual.
>
>
> I don't recall seeing anything like this for a long time. I suspect
> that your customer theory may be true.
>
>
> Chuck
>
>
>
> James and Johann, (or everyone who has this problem), which version
> of WO are you using? Are we all talking about 5.4.3 here?
>
> On 25.03.2010, at 21:38, Mike Schrag wrote:
> I don't have a patch you can easily apply. The workaround on your
> side is to not let the EO in the parent EC garbage collect
> (basically, keep a reference to the parent EO around for any EO
> that you fault into child EC).
>
> Would a parentEC.setRetainsRegisteredObjects(true) help?
>
> Also there is a EODatabaseContext.disableSnapshotRefCounting()
> method, which completely disabled the refcounting mechanism. But I
> guess that would run out of memory very fast?
>
> There's not an easy recovery from this -- you have to toss your EC
> stack ... or .. maybe you could refetch the snapshot underneath it,
> but i think you're probably left with a __retainCount of -1 at that
> point, so probably even that won't help you.
>
> No, I don't want this to occur at all :)
>
> Have a happy easter,
> Marc
>
> I think this could be fixed pretty easily in wonder by overriding
> ERXGenericRecord.__setRetainCount .. When count is set >0, call
> back to your EC and retain the object in a dict and when it drops
> to 0, release that ref.
>
> On Mar 25, 2010, at 4:25 PM, Brook, James wrote:
>
> Mike,
>
> That sounds all too familiar to me. We are experiencing errors
> just like that. We have a feature that creates nested editing
> contexts several levels deep and fetches EOs all the way down to
> the bottom. Do you know of a workaround, patch or some way to
> recover from the bug you mention? I seem to remember a similar bug
> years ago in the days when EOF kept strong references. We are
> using Wonder.
>
> Sorry for selfishly jumping in. Disappearing snapshots are causing
> us lots of pain because whole instances of our application become
> useless.
>
> --
> James
> ________________________________________
> From: webobjects-dev-bounces
> [email protected]<mailto:[email protected]>
> [[email protected]
> ] On Behalf Of Mike Schrag [[email protected]]
> Sent: 25 March 2010 20:20
> To: Marc Guenther
> Cc: [email protected]<mailto:[email protected]>
> Subject: Re: Snapshots mysteriously vanishing?
>
> by any chance was this an EO in a parent editing context that
> also existed in a child editingcontext?
>
> I don't think so, but I'm not sure. That particular EO could have
> been in all differents ECs at the time, as it's entity is used
> all over the place.
>
> Do you have anything specific in mind?
> yeah, there's a bug with refcounting of eo's in child ec's if the
> parent ec copy of the EO gets garbage collected ... the result of
> this bug is disappearing snapshots. this specifically applies to
> eo's fetched into a child that were already fetched into the
> parent, though, not to peer ec's.
>
> ms
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list
> ([email protected]<mailto:[email protected]>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/jbrook%40upcbroadband.com
>
> This email sent to [email protected]<mailto:[email protected]>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list
> ([email protected]<mailto:[email protected]>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/yoda%40schli.ch
>
> This email sent to [email protected]<mailto:[email protected]>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list
> ([email protected]<mailto:[email protected]>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>
> This email sent to [email protected]<mailto:[email protected]>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their
> overall knowledge of WebObjects or who are trying to solve specific
> problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/jsobanski%40upcbroadband.com
>
> This email sent to [email protected]
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/alexis.tual%40gmail.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
