• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Why are my EOs turning back to faults?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 14:52:11 -0700
Something is not what you think it is.  :-)


On 2012-09-05, at 2:46 PM, John Pollard 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.

So were you retaining them?  If you just fetch a graph of objects and something (the page, the session, something) does not retain a reference into that graph, it will get garbage collected.


> 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 suspect you just need to add a reference so that the graph of objects is reachable from an object that is not eligible for garbage collection.  Otherwise, have a look at ERXEOEnterpriseObjectCache.


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

I recommend not using this.


Chuck

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

--
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
References: 
 >Why are my EOs turning back to faults? (From: John Pollard <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: Chuck Hill <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: John Pollard <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: Chuck Hill <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: John Pollard <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: Chuck Hill <email@hidden>)
 >Re: Why are my EOs turning back to faults? (From: John Pollard <email@hidden>)

  • Prev by Date: Re: Why are my EOs turning back to faults?
  • Next by Date: Re: Why are my EOs turning back to faults?
  • Previous by thread: Re: Why are my EOs turning back to faults?
  • Next by thread: WORequest, Logging IP-Addresses
  • Index(es):
    • Date
    • Thread