Re: NullPointerException only after first call to batchFetchRelationship

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(EOObjectStoreCoordinator)
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>(_EOMutab 
>>>> leKnownKeyDictionary.java:90)
>>>>         at
>>>> com.webobjects.eoaccess.EORelationship._foreignKeyForSourceRow(EORela 
>>>> 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