• 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: java.lang.IllegalStateException: Cannot fire array fault with a null handler
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Lachlan Deck <email@hidden>
  • Date: Mon, 15 Dec 2008 13:52:56 +1100

On 15/12/2008, at 1:16 PM, Dov Rosenberg wrote:

Hadn't really noticed the lockForReading() and unlockForReading() methods.
Perhaps that could stop the objects from mutating while we are trying to
access them under load.

Worth a try I would suggest. The api suggests:
"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."


Looking thru the code it seems that various methods
like objectsWithFetchSpecification() etc all do a lock() and unlock()
already. If our methods were synchronized that make these calls would that
accomplish the same thing?

I think it's a question of how fine-grained you want your locking. i.e. allowing EOF to auto-lock via objectsWithFetchSpecification for example or heading towards a more block-based lock with try/catch. The question is what's happening with the database context.


I can only suggest pinging Pierre for more.

The memory usage is pretty good. The app behaves very well under load -
regular garbage collection rhythms.


None of our Entities are marked as shared in the model. We have other
applications that use the same EOModel.

Can't think of anything else at this time sorry.

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


References: 
 >Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler (From: Dov Rosenberg <email@hidden>)

  • Prev by Date: Re: Any reason why extending and extended WOComponent would not work?
  • Next by Date: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
  • Previous by thread: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
  • Next by thread: Re: java.lang.IllegalStateException: Cannot fire array fault with a null handler
  • Index(es):
    • Date
    • Thread