I think it is an actual retain count that is used. When an EO is instantiated in an an EC, the count goes up. When the EO is garbage collected, forgotten, refaulted, etc. the retain count goes down. Is this is enabled, when the retain count is 0, the snapshot is discarded.
Chuck On 2012-09-05, at 2:51 PM, Karl Gretton wrote: > As Chuck mentioned, EOs are re-faulted based upon the fetchTimestampLag. But > I believe that snapshots are always weak references and therefore subject to > being garbage collected at any time. > > Presumably setRetainsRegisteredObjects(true) changes this to a regular > reference. > > Karl > > On 2012-09-06, at 12:46 AM, John Pollard <[email protected]> wrote: > >> This problem goes away if I call setRetainsRegisteredObjects(true) on the EC >> in question. >> So presumably garbage collection was somehow resulting in the relationships >> turning into faults. >> Perhaps I should have said that the call manifests itself between separate >> requests coming in and that I am looking to cache EOs beyond a single >> request. >> I know that retaining all registered objects in the EC can lead to >> memory-hungry apps, so I'll monitor to see if that is a problem, but at >> lease I finally know where the root of the problem lies. >> >> On 5 Sep 2012, at 19:37, Chuck Hill wrote: >> >>> Something is not what you think it is. >>> >>> This trace: >>> >>>>>>> at mp.eo.StockItem.turnIntoFault(StockItem.java:1714) >>>>>>> at >>>>>>> com.webobjects.eocontrol.EOFaultHandler.makeObjectIntoFault(EOFaultHandler.java:161) >>>>>>> at >>>>>>> com.webobjects.eoaccess.EODatabaseContext._turnToFaultGidEditingContextIsComplete(EODatabaseContext.java:3363) >>>>>>> at >>>>>>> com.webobjects.eoaccess.EODatabaseContext.faultForGlobalID(EODatabaseContext.java:3397) >>>>>>> at >>>>>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.faultForGlobalID(EOObjectStoreCoordinator.java:537) >>>>>>> at >>>>>>> com.webobjects.eocontrol.EOEditingContext.faultForGlobalID(EOEditingContext.java:3608) >>> >>> Means that EOEditingContext.faultForGlobalID did NOT find an EO for that >>> global ID in that editing context. A few possibilities: >>> >>> - this StockItem is not one of the ones you have pre-loaded >>> - you pre-loaded them in a different editing context >>> - something told the EC to forgetObject() after you pre-loaded them >>> >>> >>> Chuck >>> >>> >>> >>> On 2012-09-05, at 10:30 AM, John Pollard wrote: >>> >>>> There is a to-one from WebPage to StockItem and no other direct >>>> relationship to StockItem. >>>> >>>> On 5 Sep 2012, at 18:20, Chuck Hill wrote: >>>> >>>>> Is there a to-one from WebPage to StockItem? Or is it a to-many? >>>>> >>>>> Chuck >>>>> >>>>> >>>>> On 2012-09-05, at 10:01 AM, John Pollard wrote: >>>>> >>>>>> Hi Chuck, >>>>>> The count is actually of the WebPage.childWebPages() array not on >>>>>> stockItems at all which is why I was puzzled that a >>>>>> StockItem.turnIntoFault() was being triggered. >>>>>> I confirmed that they are all in the same EC by logging the hashCode() >>>>>> of the EC (I assume that is valid) >>>>>> Thanks for your reply >>>>>> John >>>>>> >>>>>> On 5 Sep 2012, at 17:48, Chuck Hill wrote: >>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> Are StockItems "carefully pre-loaded" into the same EC as WebPages? If >>>>>>> not, you are likely running into the EC's fetch timestamp lag. It >>>>>>> looks like you are doing a count of StockItem at at >>>>>>> mp.eo.WebPage.getDescendantWebPages(WebPage.java:1410) and this is >>>>>>> causing the to-many to be faulted. >>>>>>> >>>>>>> >>>>>>> Chuck >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2012-09-05, at 9:21 AM, John Pollard wrote: >>>>>>> >>>>>>>> Hi WO list, >>>>>>>> >>>>>>>> The firing of a fault on EOs of one type is causing EOs of another >>>>>>>> type be turned into faults... is that expected? >>>>>>>> >>>>>>>> I have a WebPage eo with a to-many relationship called childWebPages >>>>>>>> (returns an array of WebPage objects) >>>>>>>> >>>>>>>> When I access this array recursively in getDescendantWebPages()...see >>>>>>>> stack trace below, a totally different class of object is turned into >>>>>>>> a fault StockItem, see top line of stack trace. >>>>>>>> >>>>>>>> I don't want EOF to turn my carefully pre-loaded StockItems back into >>>>>>>> faults! >>>>>>>> >>>>>>>> The two EOs are related via a join table. >>>>>>>> >>>>>>>> This is causing performance headaches. >>>>>>>> >>>>>>>> at mp.eo.StockItem.turnIntoFault(StockItem.java:1714) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOFaultHandler.makeObjectIntoFault(EOFaultHandler.java:161) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext._turnToFaultGidEditingContextIsComplete(EODatabaseContext.java:3363) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext.faultForGlobalID(EODatabaseContext.java:3397) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.faultForGlobalID(EOObjectStoreCoordinator.java:537) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOEditingContext.faultForGlobalID(EOEditingContext.java:3608) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext._objectFaultWithSnapshotRelationshipEditingContext(EODatabaseContext.java:2361) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext._fireDeferredFaultWithSourceObject(EODatabaseContext.java:2401) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EOAccessDeferredFaultHandler.createFaultForDeferredFault(EOAccessDeferredFaultHandler.java:49) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOCustomObject.willReadRelationship(EOCustomObject.java:1279) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol._EOMutableKnownKeyDictionary$Initializer$_LazyGenericRecordBinding.valueInObject(_EOMutableKnownKeyDictionary.java:614) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOCustomObject.storedValueForKey(EOCustomObject.java:1634) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext.databaseOperationForObject(EODatabaseContext.java:4810) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext.valuesForKeys(EODatabaseContext.java:6531) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.valuesForKeys(EOObjectStoreCoordinator.java:321) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EOQualifierSQLGeneration$_KeyValueQualifierSupport.schemaBasedQualifierWithRootEntity(EOQualifierSQLGeneration.java:439) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EOQualifierSQLGeneration$Support._schemaBasedQualifierWithRootEntity(EOQualifierSQLGeneration.java:179) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseChannel.selectObjectsWithFetchSpecification(EODatabaseChannel.java:227) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEditingContext(EODatabaseContext.java:3055) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(EODatabaseContext.java:3195) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecification(EOObjectStoreCoordinator.java:483) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:4053) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext.objectsForSourceGlobalID(EODatabaseContext.java:4084) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsForSourceGlobalID(EOObjectStoreCoordinator.java:629) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol.EOEditingContext.objectsForSourceGlobalID(EOEditingContext.java:3907) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EODatabaseContext._fireArrayFault(EODatabaseContext.java:4245) >>>>>>>> at >>>>>>>> com.webobjects.eoaccess.EOAccessArrayFaultHandler.completeInitializationOfObject(EOAccessArrayFaultHandler.java:77) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol._EOCheapCopyMutableArray.willRead(_EOCheapCopyMutableArray.java:45) >>>>>>>> at >>>>>>>> com.webobjects.eocontrol._EOCheapCopyMutableArray.count(_EOCheapCopyMutableArray.java:103) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1410) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1393) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1414) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1393) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1414) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1393) >>>>>>>> at mp.eo.WebPage.getDescendantWebPages(WebPage.java:1414) >>>>>>>> at mp.eo.WebSite.getAllWebPages(WebSite.java:842) >>>>>>>> at mpMall.DirectAction.getWebPageById(DirectAction.java:1982) >>>>>>>> at mpMall.DirectAction.viewPageAction(DirectAction.java:537) >>>>>>>> >>>>>>>> Many thanks, >>>>>>>> John >>>>>>>> _______________________________________________ >>>>>>>> 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/chill%40global-village.net >>>>>>>> >>>>>>>> This email sent to [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/gvc/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: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>>>> >>>>>> This email sent to [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/gvc/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: >>>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>> >>>> This email sent to [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/gvc/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: >> https://lists.apple.com/mailman/options/webobjects-dev/kgretton%40mac.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: > https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [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/gvc/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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
