Re: Why are my EOs turning back to faults?
Re: Why are my EOs turning back to faults?
- Subject: Re: Why are my EOs turning back to faults?
- From: Chuck Hill <email@hidden>
- Date: Wed, 05 Sep 2012 16:01:43 -0700
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@hidden> 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@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>> --
>>>>>>> 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@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>> --
>>>>> 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@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>> --
>>> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden