Re: NullPointerException only after first call to batchFetchRelationship

Lenny Marks <[email protected]> Tue, 16 Dec 2003 10:45:13 -0500
Newsgroups gmane.comp.web.webobjects.eof
Message-ID <[email protected]>
Actually that NullPointerException I had been getting, hadn't occurred  
while using multiple stacks. It was just that my call to  
registeredDatabaseContextForModel was returning two different database  
context instances(maybe a timing thing). Anyway, have you tried  
temporarily substituting the defaultEditingContext for the child  
editing context. In my case this served to flush out the real problem.

Exception was:

ava.lang.IllegalStateException: initializeObject: No snapshot for gid
_EOIntegralKeyGlobalID[UserAction (java.lang.Integer)433762]

One way or another it looks like your winding up with more than one  
EODatabaseContext instance.

-lenny


Returns the cooperating object store that is registered with the  
EOObjectStoreCoordinator  coordinator for the EOModel model.  If no  
cooperating object  store is registered for model, this method  
instantiates a new  EODatabaseContext, adds it to the coordinator, and  
returns it.

On Tuesday, Dec 16, 2003, at 03:27 America/New_York, Kaj Hejer wrote:

> Hi!
>
> Thanks for answering!
>
> I have multiple EOF stacks in two components in this application, but  
> these components are not releated to the place I get this exception.
>
>
>
> At 19:54 -0800 15-12-03, Chuck Hill wrote:
>> Yeah, that was probably me on about locking.  ;-)
>>
>> Good catch on the original problem!  I couldn't figure out what was
>> different at first then AAARAUGH - multiple EOF stacks.  How many  
>> times can
>> one person forget the same thing?  EOModelGroup().defaultGroup() is  
>> not
>> safe to use when there are multiple stacks.  I'm not using them in  
>> the app
>> where I'm prefetching which would explain why I've not seen this bug  
>> yet.
>>
>> If anyone's interested, related to this problem with
>> EOModelGroup.defaultGroup() are the methods:
>> EOModelGroup.modelGroupForObjectStoreCoordinator(EOObjectStoreCoordina 
>> tor)
>> EOUtilities.modelGroup(EOEditingContext)
>> EOUtilities.databaseContextForModelNamed(EOEditingContext, String)
>>
>> Kaj, do you have multiple EOF stacks?
>>
>> I've added a little code here with a twist on Lenny's implementation  
>> (just
>> 'cause I like to play with all the different ways from point A to  
>> point B
>> in EOF):
>> http://wodev.spearway.com/cgi-bin/WebObjects/WODev.woa/wa/ 
>> Main?wikiPage=EODa
>> tabaseContext.batchFetchRelationship
>>
>>
>> Chuck
>>
>>
>> At 09:45 PM 15/12/2003 -0500, Lenny Marks wrote:
>>> Sorry, I'd gotten mixed up on which list this was from.
>>>
>>> On Monday, Dec 15, 2003, at 20:49 America/New_York, Lenny Marks  
>>> wrote:
>>>
>>>>  I had tracked it down in my case, see if this helps you any.
>>>>
>>>>   
>>>> http://www.omnigroup.com/mailman/archive/eof/2003-August/>>>> 003393.html
>>>
>>> Of course the EOObjectStoreCoordinator should be manually locked and  
>>> unlocked in the code from that posting. (As originally pointed out  
>>> by Chuck if I remember correctly)
>>>
>>> -lenny
>>>
>>> EOObjectStoreCoordinator osc =  
>>> (EOObjectStoreCoordinator)ec.rootObjectStore();
>>>
>>> osc.lock();
>>> try {
>>>      EODatabaseContext dbContext = (EODatabaseContext)
>>>              osc.objectStoreForObject(this);
>>>
>>>      EOEntity correspondenceEntity =
>>>              EOUtilities.entityNamed(ec, "CorrespondenceEvent");
>>>
>>>      EORelationship corrRelationship =
>>>               
>>> correspondenceEntity.relationshipNamed("correspondence");
>>>
>>>       dbContext.batchFetchRelationship
>>>              (corrRelationship, correspondenceEvents, ec);
>>> } finally {
>>>     osc.unlock();
>>> }
>>>
>>>>
>>>>  On Sunday, Dec 14, 2003, at 12:08 America/New_York, Kaj Hejer  
>>>> wrote:
>>>>
>>>>>  At 08:57 -0400 17-08-03, Lenny Marks wrote:
>>>>>>  I have a direct action to render all information for a specified
>>>>>>  'Manuscript' in our database. The rendering of this page traces  
>>>>>> deep  into
>>>>>>  the manuscript's relationships and was slow so I was attempting  
>>>>>> to  use
>>>>>>  EODatabaseContext.batchFetchRelationship to limit the hits to the
>>>>>>  database. I added a method batchFetchManuscriptEvents(the root  
>>>>>> of  the deep
>>>>>>  relationships) to my Manuscript EOEnterpriseObject class. I was   
>>>>>> hoping
>>>>>>  that the application could call this in anticipation of its   
>>>>>> particular
>>>>>>  display needs. The method would batchFetch all the relationships  
>>>>>> so  that
>>>>>>  by the time the WOComponent was generating its response, all the
>>>>>>  relationships would have already been faulted. This actually  
>>>>>> worked,  but
>>>>>>  only the first time the method is invoked on a Manuscript  
>>>>>> instance  within
>>>>>>  a single EOF stack. The first time I access the direct action  
>>>>>> for a
>>>>>>  manuscript, it works, but if I hit reload I get the exception  
>>>>>> below.
>>>>>>
>>>>>>  Any clues would be greatly appreciated!
>>>>>>
>>>>>>  -Lenny Marks
>>>>>>
>>>>>>  <ManView>[2003-08-17 07:49:16 EDT] <Thread-6>
>>>>>>  java.lang.NullPointerException
>>>>>>          at
>>>>>>   
>>>>>> com.webobjects.eocontrol._EOMutableKnownKeyDictionary.<init>(_EOMu 
>>>>>> tab
>>>>>>  leKnownKeyDictionary.java:90)
>>>>>>          at
>>>>>>   
>>>>>> com.webobjects.eoaccess.EORelationship._foreignKeyForSourceRow(EOR 
>>>>>> ela
>>>>>>  tionship.java:1094)
>>  >>>
>>>>>
>>>>>
>>>>>
>>>>>  Hi!
>>>>>
>>>>>  I now saw the same exception when using prefetching.
>>>>>
>>>>>  The stacktrace and the method where I get this exception can be  
>>>>> found
>>  >>> at http://folk.uio.no/kajh/tmp/wo20031214.txt
>>>>>
>>>>>  Has anybody else here seen this?
>>>>>
>>>>>  The ec I use here is a childEC of session.defaulteditingContext  
>>>>> and  this childEC has been locked.
>>>>>
>>>>>  I have only managed to reproduced this issue two times while  
>>>>> testing  this application for about an hour, so it seems that it  
>>>>> does not  appear so very often.
>>>>>
>>>>>
>>>>>  -Kaj :)
>>>>
>>>>  _______________________________________________
>>>>  WebObjects-dev mailing list
>>>>  [email protected]
>>>>  http://www.omnigroup.com/mailman/listinfo/webobjects-dev
>>>
>>> _______________________________________________
>>> EOF mailing list
>>> [email protected]
>>> http://www.omnigroup.com/mailman/listinfo/eof
>>>
>>
>> --
>>
>> Chuck Hill                                 [email protected]
>> Global Village Consulting Inc.              
>> http://www.global-village.net
>
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof