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