On Mar 5, 2014, at 8:38 AM, David Avendasora <[email protected]> wrote:
> Ramsey, I could kiss you! > > On Mar 4, 2014, at 3:01 PM, David Avendasora <[email protected]> > wrote: > >> It sounded promising, but unfortunately this did not fix it. It appears to >> be something I’m doing wrong. > > Apparently what I was doing wrong was not actually using your solution on the > EC that was the culprit. > > In hindsight it all makes sense. If I create and save, or insert an EO into > an EC and then not touch it again while I create dozens of nested ECs with > nested ECs of their own, always local instancing the original EO into them, > doing lots of work with multiple saves and reverts on each one using more an > more memory, eventually Java says “Hey, you. Yes you! You pathetic > weakly-linked snapshot of MYEntity hiding in the corner over there. You are > garbage. Nobody wants (links to) you. Die. Die! DIE! DIEDIEDIEDIEDIEDIE…. > > er… > > oh. > > Right. > > Setting the right EC to retain registered objects did the trick. MYEntity has > proof he is loved now and nobody… ah hell, are you still here? > > The EOF documentation points out the one-sided relationship of unchanged-EOs > and ECs, but does not go into the possible implications for the EO itself > (Page 81 of WebObjects Enterprise Objects Programming Guide): > > <snip> > You usually do not need to worry about managing memory in an Enterprise > Objects application, but this section may be interesting for advanced users. I think the documentation just referred to you as an advanced user Dave :D > EOEditingContexts use weak references to the EOEnterpriseObjects registered > with them. EOEnterpriseObjects hold a strong reference to the > EOEditingContext in which they are registered. These types of references > prevent an EOEditingContext from being garbage collected while an > EOEnterpriseObject still requires it. There are several exceptions: > > EOEditingContexts hold all inserted, deleted, or updated objects by strong > references. These strong references are cleared by the EOEditingContext > methods saveChanges, revert, invalidateAllObjects, and reset. They may also > be cleared by the EOEditingContext methods invalidateObjectsWithGlobalIDs, > refaultObject, refreshObject, undo, and redo, depending on whether the > changed state is or is not forcefully discarded. > > EOEnterpriseObjects registered with an EOSharedEditingContext are always held > by strong references. > > You can force an EOEditingContext to hold strong references to all of its > EOEnterpriseObjects by invoking either setInstancesRetainRegisteredObjects or > setRetainsRegisteredObjects on an editing context in which no enterprise > objects are registered. > > </snip> > >> You know, you could at least *pretend* to be surprised. > > Pfft. Nobody around here is surprised at your ability to do things wrongly. > It’s what you’re good at. Embrace it. Allow others to learn from your … > talent. > >> No? > > No. > >> grumble… > > Cheer up! It could be worse, you could be one of the other Dave’s on the > list; always having to say “No, not *that* Dave!" > >> Dave >> >> >> On Mar 4, 2014, at 1:05 PM, Ramsey Gurley <[email protected]> wrote: >> >>> Are you using nested ecs? If you are, try >>> ec.setRetainsRegisteredObjects(true). >>> >>> https://github.com/wocommunity/wonder/pull/342 >>> >>> On Mar 4, 2014, at 9:35 AM, David Avendasora <[email protected]> >>> wrote: >>> >>>> Hey all, >>>> >>>> I’m getting the following exception (I added line breaks to make it >>>> digestible by any on the list): >>>> >>>> IllegalStateException: rowDiffsForAttributes: snapshot in >>>> com.webobjects.eoaccess.EODatabaseOperation >>>> { >>>> _dbSnapshot = {}; >>>> _entity = "MYEntity"; >>>> _newRow = >>>> { >>>> whatsit = "PHONE"; >>>> whosit = false; >>>> chuckIt = false; >>>> id = 3451; >>>> }; >>>> _object = "<com.nekesto.neo.model.MYEntity pk:"3451">"; >>>> _globalID = _EOIntegralKeyGlobalID[MYEntity (java.lang.Long)3451]; >>>> _databaseOperator = "EODatabaseUpdateOperator"; >>>> } does not contain value for attribute named chuckIt with snapshot key: >>>> chuckIt >>>> >>>> I can see that the _dbSnapshot is completely empty and I know that that is >>>> what it’s complaining about. The object exists in the DB with a PK >>>> matching the id value, which matches up with the _object and the >>>> _globalID. How could the _dbSnapshot end up empty? What >>>> horribly-inappropriate thing have done? >>>> >>>> I have gone over everyplace I instantiate “MYEntity” and I’m never using >>>> the EO’s constructor, it’s always being done by >>>> ERXEOControlUtilities.createAndInsertObject(editingContext, “MYEntity”). >>>> >>>> As far as I can tell I’m never crossing EC boundaries without >>>> localInstancing it. >>>> >>>> Is there anything else that can cause the _dbSnapshot to be empty? >>>> >>>> I’m making use of multiple EOObjectStoreCoordinators, 1 each for two >>>> different EOModelGroups, but this code should only ever be using the >>>> defaultModelGroup in the defaultObjectStoreCoordinator. So I don’t *think* >>>> it has anything to do with that, but, well, I’m me and I do stuff all the >>>> time that future me is shocked at. >>>> >>>> Dave > > ————————————————————————————— > WebObjects - so easy that even Dave Avendasora can do it!™ > ————————————————————————————— > David Avendasora > Senior Software Abuser > Nekesto, Inc. > > >
_______________________________________________ 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]
