My application uses a Core Data model on two threads - the main UI thread and a worker thread. Each thread has its own private managed object context as per Apple's recommendation. The managed object contexts share a single persistent store coordinator.
Only my worker thread modifies the managed objects. The main thread just displays them in the UI (using bindings) where none of the properties are editable. I'm uncertain about whether or not I should be locking that persistent store coordinator. Under "General Guidelines" of the "Multi-Threading with Core Data" section of the "Core Data Programming Guide", it mentions 3 patterns. I am using pattern #1 which says about locking: "If you want to aggregate a number of operations in one context together as if a virtual single transaction, you can lock the persistent store coordinator to prevent other managed object contexts using the persistent store coordinator over the scope of several operations." I don't need transaction support since as I said, the UI thread never modifies the objects. Further on, in the "Locking" section of the document, it says this: "Generally, you only need to lock a managed object context (and not even then if you ensure that each thread has its own private context, as described in “General Guidelines”). If you do choose to share a managed object context or a persistent store coordinator between threads, you must ensure that any method invocations are made from a thread-safe scope." The only time I "share" a persistent store coordinator between the threads is when I first create the two managed object contexts. So do I still need to lock the persistent store coordinator? I'd appreciate any feedback. Thanks, Mike _______________________________________________ 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 arch...@mail-archive.com
