• 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: CoreData - sqlite - statement is still active
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData - sqlite - statement is still active


  • Subject: Re: CoreData - sqlite - statement is still active
  • From: Terrence Talbot <email@hidden>
  • Date: Fri, 7 Oct 2005 17:53:58 -0700


On Oct 6, 2005, at 3:30 PM, Bill Bumgarner wrote:

On Oct 6, 2005, at 12:03 PM, Terrence Talbot wrote:

No, that's the thing: this should be a very straightforward exercise. Single document, single context, single thread. The only diddling I've done is a .dump (and now some selects, see below) of the document on the command-line to make sure the rows for these objects are there. They are...



Ok, following up from off-line conversations:

This did turn out to be a threading problem. Although my code wasn't intentionally touching the context outside of the default thread, it turns out that WebKit was calling into my code, via WebFrame's - loadRequest: method, from a different thread. That sequence, in turn, caused the context to execute fetches in other than the main thread. Blammo!

via Chris Hanson:

"You cannot access the same managed object context from multiple threads at once without locking the context appropriately. What's more, you cannot lock the context appropriately if some of that access happens as a result of bindings, since bindings aren't thread- safe. ... I strongly recommend either using a separate context in the thread invoking your implementation of -loadRequest:, or using some cross-thread communication mechanism to ensure that all access to your primary managed object context happens on the main thread."

In my case, I don't think bindings are the issue, but that's certainly worth pouring over in case anyone runs into similar. I also can't really alter -loadRequest: as the threading that's going on is deep inside WebKit, but I will think about that over the weekend.

My naive approach, which is actually working, is to have the the context -lock and -unlock itself in the - objectsWithEntityName:predicate:error method I included in a previous post in this thread. (That method actually has a zombie problem in that fetchedObjects is released before it's potentially used in a log, so fix that if you use it.) I also have to override valueForKey: in my managed object subclass and lock/unlock the context there. That works. My app *doesn't* crash.

It's not a performance win, but at least my beta testers can move on and I can spend the weekend figuring out a better solution.

Whew!

Thanks to b.bum and Chris.


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: CoreData - sqlite - statement is still active
      • From: Terrence Talbot <email@hidden>
References: 
 >CoreData - sqlite - statement is still active (From: Terrence Talbot <email@hidden>)
 >Re: CoreData - sqlite - statement is still active (From: Bill Bumgarner <email@hidden>)
 >Re: CoreData - sqlite - statement is still active (From: Terrence Talbot <email@hidden>)
 >Re: CoreData - sqlite - statement is still active (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Bindings and Core Data question.
  • Next by Date: Best way of doing a toolbar
  • Previous by thread: Re: CoreData - sqlite - statement is still active
  • Next by thread: Re: CoreData - sqlite - statement is still active
  • Index(es):
    • Date
    • Thread