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. 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]
