On Oct 9, 2008, at 2:44 AM, Ruotger Skupin wrote:
Hi,
Since Ron asked, let's move this to an own thread (no pun intended):
Am 08.10.2008 um 18:23 schrieb Ron Lue-Sang:
Hi,
I have a core data database with two contexts attached to it. One
read-only for the main thread and bindings, one read/write for a
background thread that takes data from the network and feeds it
into the database. I know this is an effed-up design you shouldn't
copy, but it won't change.
(For why this is a bad idea: http://lists.apple.com/archives/Cocoa-dev/2007/May/msg00066.html
but please let's not discuss this here, thx)
Where shall we discuss this then? I have comments =)
Here. Go ahead!
Ok! From the historical post, there are these items
4. The context seems to lock the store coordinator during a save!!!
(ouch!)
Yea. For multi-threaded programming correctness, you want this. The
coordinator level snapshots need to be updated, if you have multiple
contexts all in different threads and connected to the same
coordinator, you really want those contexts to leave the coordinator
in a consistent state. So, locking – Yay! And don't forget that when
YOUR code is fiddling with the coordinator, you're gonna want to lock
it too – like when adding or removing a store.
5. The data of an object is not automatically obtained from the
store. When the data is accessed and it's not there, it then is
obtained from the store. This is called a fault, firing a fault or
faulting. (I haven't got the hang of this part of the terminology yet)
Fault - your managed object when it doesn't have any of your data in
it yet.
Firing a fault - filling in your managed object with your data
Faulting - the general technique for making objects cheap by not
filling in their data until it's asked for
Read this link.
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdFaultingUniquing.html#/
/apple_ref/doc/uid/TP30001202-185436-TPXREF147
Read it like you mean it.
6. The context locks the store coordinator during the firing of a
fault (at least partially).
I'm not sure whether this is meant as a bad thing or not. Like item #4
above, it's a necessary thing when doing MT programming. The
coordinator keeps a cache of object values. When a fault gets fired,
its data comes from the coordinator. The coordinators cache can be
updated. The lock is necessary to ensure consistency.
7. Bindings tend to sometimes access an object's data at surprising
(or at least uncontrollable) times.
For the most part, if a view is onscreen, its bound properties are
going to need data. Your textField bound to your arrayController of
Person's showing the selection's firstName – the textField's gonna
need to get aPerson object's firstName. If your aPerson object is a
fault, when the binding asks [aPerson valueForKeyPath:@"firstName"],
that'll fire the fault. Yes, that'll mean locking the context and the
coordinator.
Now, after all that, hopefully this next part will make more sense.
If you hate lock contention on your main thread, use a separate
CoreData stack for each thread. Not just a different context, a
different stack.
See item 2 here
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html#/
/apple_ref/doc/uid/TP40003385-SW2
You don't get the shared row cache between threads, but the only
locking that'll happen is at the store file level, which for the
SQLite store is fast (I'm directly disputing item 3 in the post, which
I haven't copied here). With this design, long save operations on the
background thread shouldn't hang your UI thread.
--------------------------
RONZILLA
_______________________________________________
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]
