On Oct 16, 2008, at 3:59 PM, Dave Dribin wrote:
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote:
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
Hi Melissa,
Thanks for your help. A quick question on this stale data statement:
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote:
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 loa
On Oct 15, 2008, at 17:41, Dave Dribin wrote:
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote:
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 d
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
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
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
