On Oct 15, 2008, at 14:00, Dave Dribin wrote:
Hello,
I'm working on a Core Data application that does lots of processing
of the data in background threads to generate reports. I'd like to
investigate using multiple persistent store coordinators to reduce
lock contention, i.e. pattern #2, as described in the multi-threaded
chapter of the Core Data guide.
I'm thinking it is a good fit in this case as the background threads
are doing mainly read-only operations on the data. It does modify
transient properties, but I think I can still get away with using a
read-only store on the background threads. Is this correct?
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.
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.
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.
+Melissa
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
