Re: Basic Coredata / threading question
Re: Basic Coredata / threading question
- Subject: Re: Basic Coredata / threading question
- From: Scott Stevenson <email@hidden>
- Date: Sat, 7 Apr 2007 00:02:27 -0700
On Apr 6, 2007, at 12:26 PM, Walt Horat wrote:
It seems that if each thread is given its own managed object
context, the app will have N copies of the model all in memory at
the same time - this does not sound like a good strategy for large
datasets.
A Managed Object Model is relatively small. It's a description of
your schema. Loading it in multiple times should not be a problem in
most cases, and isn't affected by the size of your data set.
I suspect you're using the word "model" in a different way than Core
Data defines it, though I'm not sure what you mean instead. Rails,
for example, sometimes uses the word "model" to refer to what Core
Data would call a "Managed Object".
As a solution, I have tried implementing each thread so as to send
a dictionary of non-managed objects over to the main thread (using
NSObject performSelectorOnMainThread) to actually do the work.
You can pass objectIDs between threads safely, and retrieve the
"real" object on the other end using that objectID. Does that make
sense?
This seems to work, until the next time the app. tries to save the
model - it deadlocks inside of the call to save. It is unclear whom
is locking what as I can see that all of the network threads have
already completed.
Are you doing locking yourself? If so, where?
I know you shared examples of locking inside the accessors, but I
took that as something you were considering, not something which was
actually implemented.
I am considering trying to simplify the design doing what I am told
is bad - to have the threads share the same managed object context.
Don't do that. :) It's better for each thread to have its own
Managed Object Context and to pass objectIDs back and forth.
- Scott
(Side note: Please make sure to create a new messages when posting to
the list. Replying to an existing message on a different topic may
mean your question gets lost.)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden