Re: Multiple persistent store coordinators gotchas?
Re: Multiple persistent store coordinators gotchas?
- Subject: Re: Multiple persistent store coordinators gotchas?
- From: Dave Dribin <email@hidden>
- Date: Wed, 15 Oct 2008 19:41:01 -0500
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote:
If your second thread is doing pure report generation, and whatever
transients it sets won't affect anything outside the report
generation, this is the solution you're looking for.
Great, thanks!
The documentation is a little thin about using multiple PSCs. Is
it just a matter of setting up separate Core Data stacks per thread?
Yes.
What are the downsides, especially compared to 1 PSC/multiple
MOCs? Higher memory usage? Separate caches? Stale data?
Anything else to watch out for?
The downside tends to be more memory use, since you'll have two
copies of all the data for each object that is loaded into both
stacks in addition to the overhead of the stack itself. Stale data
is unlikely to be a problem unless you're expecting to load it
significantly before you actually need it, which would be the same
if you were loading it into a separate context on the same
coordinator.
Okay, great. This sounds ideal. One clarification. When you say
"two copies of all the data", doesn't this happen if you had 1 PSC and
2 MOCs, too? Each MOC has it's own copy of the data, since they don't
share managed objects, right? Or is there some other data that is
shared in the PSC?
The big upside is that it decreases the amount of time your UI
thread will be blocked on reads being done by the background thread.
Precisely. I'm seeing some lock contention between the threads, and I
want to reduce/eliminate that. BTW, this is a SQLite store. Do
fetches do an exclusive SQL transaction, or is that only done for
saves? Just curious if SQLite's locking will affect the threads at
all, as we're seeing some fetches take a relatively long time (~3
seconds). Ideally, the SQLite database won't be locked for that
period, either, which would also block the UI thread.
-Dave
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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