Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
- Subject: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
- From: Dov Rosenberg <email@hidden>
- Date: Sun, 14 Dec 2008 21:23:25 -0500
- Thread-topic: java.lang.IllegalStateException: Cannot fire array fault with a null handler
Title: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
According to the docs for EOSharedEditingContext:
In multithreaded applications, shared objects can be used safely by many threads at once. Shared editing contexts use NSMultiReaderLocks to maintain thread safety. The methods objectsWithFetchSpecification bindObjectsWithFetchSpecification, faultForGlobalID, and objectForGlobalID are thread safe, but the context must be locked before using any other shared context API.
We use EOUtilities.objectWithPrimaryKey() which uses objectsWithFetchSpecification() internally.
Dov
On 12/14/08 8:42 PM, "Lachlan Deck" <email@hidden> wrote:
> Hi Dov,
>
> On 15/12/2008, at 12:11 PM, Dov Rosenberg wrote:
>
>> We are using WO 5.4.3. We are also use Project Wonder. Not sure how to
>> figure out the Project Wonder version, but it is the latest as of
>> November.
>
> ok
>
>> I am actually suprised that my stacktrace doesn’t have any Project
>> Wonder
>> classes in it since we are extending ERXEC and such. Perhaps because
>> this
>> editing context is the EOSharedEditing Context.
>
> Correct. EOSharedEditingContext does not extend ERXEC. But that's a
> different issue.
>
>> Here are the decompiled
>> lines of WO code that the stack trace is referring to:
>>
>> com.webobjects.eoaccess.EODatabaseContext.java
>> public void _fireArrayFault(Object fault) {
>> EOAccessArrayFaultHandler handler =
>> (EOAccessArrayFaultHandler)EOFaultHandler.handlerForFault(fault);
>> if(handler == null) throw new
>> IllegalStateException("Cannot fire
>> array fault with a null handler.");
>> ....
>>
>> MyCode.java
>> NSArray roles = user.securityRoles(); if (roles != null)
>> { for
>> (int i = 0; i < roles.count(); ++i) { <--- roles.count() starts the
>> stacktrace. User.securityRoles() returns data under the same user
>> while not
>> under concurrent load. The roles array appears to be valid since it
>> passes
>> the NULL check
>
> Yeah - the problem is that for some reason (yet unknown) the array
> fault is botched.
> I'd suggest pinging Pierre on this one.
>
> The questions you skipped though could be helpful:
> - memory usage?
> - anything special about the entities triggering this? (e.g.,
> inheritance) Is it marked as shared in the model?
>
> - are you using locking? Or have you tried using locking? i.e., ERXEC
> auto-locking does *not* apply to EOSharedEditingContext.
>
> EOSharedEditingContext.defaultSharedEditingContext().lockForReading();
> try
> {
>
> }
> finally
> {
>
> EOSharedEditingContext.defaultSharedEditingContext().unlockForReading();
> }
>
>
>> On 12/14/08 6:51 PM, "Lachlan Deck" <email@hidden> wrote:
>>
>>> On 14/12/2008, at 4:10 AM, Dov Rosenberg wrote:
>>>
>>>> We don’t throw these errors if we try to debug and step thru the
>>>> code – only
>>>> under load. These particular EO’s come from the infamous
>>>> SharedEditingContext. We use the SharedEditingContext because this
>>>> portion
>>>> of the app is READONLY and it allows us to share the data between
>>>> sessions
>>>> instead of having to refetch is for every session.
>>>
>>> Memory usage? Any particular entities that trigger this? (e.g., any
>>> inheritance).
>>> How are you faulting the data? Locking?
>>>
>>>> Any thoughts would be appreciated
>>>
>>> with regards,
>>> --
>>>
>>> Lachlan Deck
>>>
>>
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
_______________________________________________
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