xCode 7.3 demo

Parent-Child Contexts

An important point that you need to get a good grip on is that contexts can be chained such that one is the child of another.

CoreDataStack.h

CoreDataStack.m

We create a private (child) and parent context.
The parent is what connects to the Persistent Store Coordinator.
The child is connected to the parent context through the parentContext property.
The child DOES NOT connect to the PSC.

If and when you do this, you have to realize that:

• Changes saved in a child context are pushed to the parent, not to the persistent store.
• The parent context behaves as the child’s persistent store.
• Changes saved in a parent are not pushed down to the child.
• Changes saved in a sibling are not pushed to other siblings.

This means that changes only propagate one level up in a context hierarchy. If the context you are saving is several levels away from the persistent store, you will need to save each parent context in the hierarchy until you reach the context that saves to the persistent store to actually persist your changes.

Demo – Changes saved in an child context are pushed to the parent

First click the Show Private Context Button.

output:
(PRIVATE CONTEXT) – no people found

Do the same for “Show Parent Context” and you’ll get the same output.

Hence, we know that both child/parent contexts do not have any data so far.

Okay, Let’s first add some objects.

We first put a block task onto the private context. Its basically adding three Person objects.
Once those objects are initialized, we tell the context to save.

Press the ‘add bulk’ button do add the objects.

output:
——– ADD BULK PEOPLE ———–
added remark: 1472782237.562826 1472782237.562826
added remark: 1472782237.563077 1472782237.563077
added remark: 1472782237.563318 1472782237.563318
PRIVATE CONTEXT save success!

Now, if you click the “Show Pvt Context” button and “Show Parent Context” button, you’ll see that they both show data. This is because when the private context saves its data, it pushes it up to the parent automatically.

output:

(PARENT CONTEXT) —— RESULTS ————
There are 3 number of entries so far
0 —————-
firstName = remark: 1472782941.371055
lastName = 1472782941.371055
object address is: 0x7f835bf11150
….
…

What happens to the parent context if child does not save?

Let’s edit the first object by pressing the “Pvt Context, [0] to Ricky” button.
We put a task block onto the private context. It gets the first object, and changes
the first name to “Ricky”

output:

PRIVATE CONTEXT — CHANGE FIRST PERSON TO RICKY… ————

Then have the private context display its results. You will see that Ricky appears.

output:

(PRIVATE CONTEXT) —— RESULTS ————
There are 3 number of entries so far
…
0 —————-
firstName = RICKY
lastName = 1472783378.062207
object address is: 0x7f8bc161d400

But if you display the PARENT CONTEXT, you will not see it. The reason why is because you need to save the private context in order
to propagate the changes up the parent.

Try clicking on the “Save Pvt context” button. You’ll see this:
PRIVATE CONTEXT save success!

Then click the “Show Parent Context” button and you’ll see Ricky in the results:

output:

(PARENT CONTEXT) —— RESULTS ————
There are 3 number of entries so far
…
0 —————-
firstName = RICKY
lastName = 1472783378.062207
object address is: 0x7f8bc161b390

Now, press the “Main Context Display All”, you’ll see that its empty:

That’s because each save only propagate up one level. Thus, in order for the changes to be saved into the PSC, 2 points must hold:

1) The context must be connected to the PSC
2) The context’s parent context must be nil.

Our parent context satisfies both.

Click on “Main Context Display All”. You’ll still get:

There are no people in the data store yet. We need to make sure each context saves to propagate the changes up.

Now, save the parent context by clicking on “Save Parent Context”.

Due to the parentContext’s PSC is set, and that its parent context is nil, its saves will reflect to the PSC.

Thus, whatever context that’s connected to the PSC will be able to see the results.
Click on “Main Context Display All” and you’ll see that our main context now has the results:

(MAIN CONTEXT) —— RESULTS ————
There are 3 number of entries so far
…
firstName = RICKY
lastName = 1472784795.060829
object address is: 0x7fac7acbbeb0

xCode 7.3 demo, AsyncFetchRequestEx1

Setting up the Stack

We create the core data stack called BNRCoreDataCoordinator.

Then we set up the PSC and MOC…

1) Set up lazy loading accessor for NSPersistentStoreCoordinator
2) Set up lazy loading accessor for NSManagedObjectContext

Notice that the MOC is connected to the PSC:

MOC Saving

Inserting Data

We throw a task block on our MOC’s private background queue. That task to simply initialize an Entity object
n number of times. Core Data returns ready objects for us to initialize. Once all the Entity objects are set up,
we tell the MOC to save context.

The caller of this method will get a completion block to signify that our Entity insertions have been done.
We throw this completion block onto the main queue visual reply.

How To Use

In your ViewController, import the core data coordinator, and implement a lazy loading accessor.

Let’s insert the data when it first appears. As you can see, when the insertion have completed,
we can do something on the UI, or just log a completion message.

CoreData Stack #3 xCode 7.3

ref – http://blog.chadwilken.com/core-data-concurrency/
http://stackoverflow.com/questions/30089401/core-data-should-i-be-fetching-objects-from-the-parent-context-or-does-the-chil
https://github.com/skandragon/CoreDataMultipleContexts

https://medium.com/bpxl-craft/thoughts-on-core-data-stack-configurations-b24b0ea275f3#.vml9s629s

In iOS 5, Apple introduced

• 1) parent/child contests – settings a context as a child to a parent context is that whenever the child saves, it doesn’t persist its changes to disk. It simply updates it own context via a NSManagedObjectContextDidSaveNotification message. Instead, it pushes its changes up to its parent so that the parent can save it.
• 2) concurrency queue that is tied to a context. It guarantees that if you execute your code block using that context, it will use execute your code block on its assigned queue

Thus, we can use parent/child contexts and concurrency queue to set up our Core Data Stack.

Say we create a parent context. It will act as the app’s Task Master. Its children will push their changes up so that the task master will and executes them in a background queue.

When creating this Task Master context, we init it with macro NSPrivateQueueConcurrencyType to let it know that the queue is a private one. Because its a private queue, the threads used to run the tasks in this private queue will be executed in the background.

Now, let’s a child context. We we create a temporary MOC who’s parent context is our Task Master.

Notice its parentContext assigned to our Task Master.

This implies that whenever our temporary MOCs finish their tasks, (whether its getting data from the net or reading in loads of data from somewhere or whatever task that takes quite a bit of time) and that we call MOC’s save,
this does 2 things:

1) save sends the NSManagedObjectContextDidSaveNotification message, and thus our Notification center observes. We go to handleMOCDidSaveNotification method where we call a method for the parentContext (task master) to do the save.

2) The background context’s changes are pushed into its parent context (task master).

Here is the handler that handles all name:NSManagedObjectContextDidSaveNotification message triggered by our child temporary MOCs.

where handleMOCDidSaveNotification is:

In handleMOCDidSaveNotification, we ignore other context, we take care of these temporary MOCs only. We RETURN and do nothing iff the temp MOCs are NOT tracked in our NSHashTable directory, or if its the UI context.

If the temp MOCs ARE tracked, that means they are temp MOCs, and we go ahead merge our temp MOCs with the UI MOC. We merge our changes with the UI MOC, because the UI MOC is not a parent context of the temp MOCs. The UI MOC is a separate entity.

When a MOC saves, its changes are pushed into its parent context. These however are not immediately written to disk. We write to the disk, after the background MOC saves, sends the NSManagedObjectContextDidSaveNotification notification, we go into handleMOCDidSaveNotification, and in the method saveMasterContext. saveMasterContext saves our parent private context, thus making it write to disk, and if it takes a long, its ok because its a private background queue.

http://stackoverflow.com/questions/30089401/core-data-should-i-be-fetching-objects-from-the-parent-context-or-does-the-chil

In short,

To clear up the confusion: after creating the child context from a parent context, that child context has the same “state” as the parent. Only if the two contexts do different things (create, modify, delete objects) the content of the two contexts will diverge.

So for your setup, proceed as follows:

create the child context
do the work you want to do (modifying or creating objects from the downloaded data),
save the child context
At this stage, nothing is saved to the persistent store yet. With the child save, the changes are just “pushed up” to the parent context. You can now

save the parent context
to write the new data to the persistent store. Then

update your UI,
best via notifications (e.g. the NSManagedObjectContextDidSaveNotification).

http://stackoverflow.com/questions/7718801/is-a-gcd-dispatch-queue-enough-to-confine-a-core-data-context-to-a-single-thread?lq=1

Concern
One big advantage of GCD dispatch queues is that it manages and makes use of multiple threads to process its FIFO tasks as needed. Each task gets executed by one thread. However, the it “may” be a different thread that processes the next task.

So – if I understand this right – tasks I hand off to one and the same dispatch queue, could end up running in different threads, potentially handing off a core data context from one thread to another, and having things go wrong. Is that right?

Answer
The accepted answer to that question, using GCD queues, does ensure that a new context is created on each thread, but does not point out the necessity of doing this.

The big thing you need to remember is that you must avoid modifying the managed object context from two different threads at the same time.

That could put the context into an inconsistent state, and nothing good can come of that. So, the kind of dispatch queue that you use is important: a concurrent dispatch queue would allow multiple tasks to proceed simultaneously, and if they both use the same context you’ll be in trouble.

If you use a serial dispatch queue, on the other hand, two or more tasks might execute on different threads, but the tasks will be executed in order, and only one task will run at a time. This is very similar to running all the tasks on the same thread, at least as far as maintaining the context’s consistency goes.

See this question and answer for a much more detailed explanation.

This is how Core Data has always worked. The Concurrency with Core Data section of the Core Data Programming Guide gives advice on how to proceed if you do decide to use a single context in multiple threads. It talks mainly about the need to be very careful to lock the context any time you access it. The point of all that locking, though, is to ensure that two or more threads don’t try to use the context simultaneously.

Using a serialized dispatch queue achieves the same goal: because only one task in the queue executes at a time, there’s no chance that two or more tasks will try to use the context at the same time.

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/ChangeManagement.html
http://stackoverflow.com/questions/4800889/what-does-apple-mean-when-they-say-that-a-nsmanagedobjectcontext-is-owned-by-the

Multiple Contexts manipulating the Database

source download

Let’s see what happens when we have 2 contexts making changes to the database. First let’s add in an extra NSManagedObjectContext called privateQueueContext2. Implement the custom set method and create our context to execute tasks on a queue.

Then synthesize it and create the custom set method.

CoreDataStack.m

How we want to test it

We’re going to test what happens when 2 contexts edit a database by having the first context get the first Person and change its name to “Ricky”, then save the context. Then we’re gunna have the second context get the first Person and change its name to “Shirley”. The change, and its related saves will be overlapped.

But first, let’s implement the code where the contexts edit a common object (0-th indexed object of the fetched result array), then do a context save.

We do this for private context queue 1:
1) We have changeFirstPersonPrivateQueue method which responds to a button that changes the 0th Person object’s name attribute to Ricky.
2) Then we have privateQueueContextOneSave method which responds to a button that wants context 1 to save.

I want to emphasize that

We do this for private context queue 2:
1) We have changeFirstPersonPrivateQueue2 method which responds to a button that changes the 0th Person object’s name attribute to Shirley.
2) Then we have privateQueueContextTwoSave method which responds to a button that does context 2 save.

Now that the implementation is ready hook up these methods to buttons.

Specifically what we’re trying to do is

to have context 1 be able to make a change to the first Object, then save it.
to have context 2 be able to make a change to the first Object, then save it.

Hence we should have 4 buttons.

Now, we know if one context makes “changes and save immediately”, then it gets reflected in the database. The next context that either reads or make further changes will see the updates. However, what if the 2 contexts’s changes and saves overlap each other?

Let’s look at this example:

• First, click on the “add bulk” button to add Person objects into Core Data.
• Then, click on the “Display All” button to show all the first/last name of the Person objects.
• Then, we use context 1 to change the 1st Person object’s first name to “Ricky”. Click the “Context1, make change to Ricky” button to edit Object 1’s name to “Ricky”.
• Then, we use context 2 to change the 1st Person object’s first name to “Shirley”. Click the “Context2, make change to Shirley” button to edit Object 1’s name to “Shirley”.
• Then click on “Context 2 save”
• Then click on “Context 1 save”

In this case, you’ll get an error:


2015-10-27 00:29:56.801 CoreData2[48750:5178513] Unresolved error Error Domain=NSCocoaErrorDomain Code=133020 “(null)” UserInfo={conflictList=(
“NSMergeConflict (0x7f96bbc0f100) for NSManagedObject (0x7f96bbd0aa90) with objectID ‘0xd000000000040000 ‘ with oldVersion = 1 and newVersion = 2 and old object snapshot = {\n firstName = \”remark: 1445930979.058863\”;\n lastName = \”1445930979.058863\”;\n} and new cached row = {\n firstName = SHIRLEY;\n lastName = \”1445930979.058863\”;\n}”
)}, {
conflictList = (
“NSMergeConflict (0x7f96bbc0f100) for NSManagedObject (0x7f96bbd0aa90) with objectID ‘0xd000000000040000 ‘ with oldVersion = 1 and newVersion = 2 and old object snapshot = {\n firstName = \”remark: 1445930979.058863\”;\n lastName = \”1445930979.058863\”;\n} and new cached row = {\n firstName = SHIRLEY;\n lastName = \”1445930979.058863\”;\n}”
);
}

..and you’ll come to the abort method:

1 2 3 4 5 6 7 8 9 10 11 12

-(void)queueOneSaveContext {   ....         NSError *error = nil;         if ([privateQueueContext hasChanges] && ![privateQueueContext save:&error])         {             // Replace this implementation with code to handle the error appropriately.             // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.             NSLog(@"Unresolved error %@, %@", error, [error userInfo]);             abort();         }    ..... }

ref – https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/ChangeManagement.html

If your application contains more than one managed object context and you allow objects to be modified in more than one context, you need to be able to reconcile the changes. This is a fairly common situation when an application is importing data from a network and the user can also edit that data.

Ultimately there can be only one truth, and differences between these views must be detected and reconciled when data is saved. When one of the managed object contexts is saved, its changes are pushed through the persistent store coordinator to the persistent store. When the second managed object context is saved, conflicts are detected using a mechanism called optimistic locking. How the conflicts are resolved depends on how you have configured the context.

When Core Data fetches an object from a persistent store, it takes a snapshot of its state. A snapshot is a dictionary of an object’s persistent properties—typically all its attributes and the global IDs of any objects to which it has a to-one relationship. Snapshots participate in optimistic locking. When the framework saves, it compares the values in each edited object’s snapshot with the then-current corresponding values in the persistent store.

• If the values are the same, then the store has not been changed since the object was fetched, so the save proceeds normally. As part of the save operation, the snapshots’ values are updated to match the saved data.
• If the values differ, then the store has been changed since the object was fetched or last saved; this represents an optimistic locking failure. The conflict must be resolved.

Say in our example, when our contexts gets the first object in our Core Data, it does so using

1	[[self privateQueueContext] executeFetchRequest:request error:nil];

as you can see in the code. Basically, the NSArray you get back is a snapshot of its state. Within the NSArray, we get the 0-th index object, and change its attribute. What we’re changing here is just a snapshot. Now, when you decide to save after you change the attribute in the situation of the 2nd context changing the name to Shirley, it compares the values in its object’s snapshot with the then-current corresponding values in the persistent store.

Context 2 – no conflict

In our case for context 2, before it saves, it sees that the current corresponding value in the persistent store is the same as the values in the snapshot it received. In both cases, it is the default value “remark: whatever today’s date is”. Since they are the same, then the store has not been changed by other context(s) since context 2 fetched it, and thus the save proceeds normally.

Context 1 – conflict

It does not work for context 1 because when context 1 fetches the object, its snapshot is “remark: whatever today’s date is”.

However, because context 2 previously managed to change the 0th Person object’s name attribute to “Shirley” and then save. This means the current corresponding values in the persistent store is Shirley.

This means the values differ, and thus, for context 1, the store has been changed since the object was fetched or last saved. This represents an optimistic locking failure. And the conflict must be resolved.

Resolving conflicts by synchronizing changes between our contexts

If you use more than one managed object context in an application, Core Data does not automatically notify one context of changes made to objects in another. In general, this is because a context is intended to be a scratch pad where you can make changes to objects in isolation, and you can discard the changes without affecting other contexts. If you do need to synchronize changes between contexts, how a change should be handled depends on the user-visible semantics you want in the second context, and on the state of the objects in the second context.

Consider an application with two managed object contexts and a single persistent store coordinator. If a user deletes an object in the first context (moc1), you may need to inform the second context (moc2) that an object has been deleted. In all cases, moc1 automatically posts an NSManagedObjectContextDidSaveNotification notification via the NSNotificationCenter that your application should register for and use as the trigger for whatever actions it needs to take. This notification contains information not only about deleted objects, but also about changed objects. You need to handle these changes because they may be the result of the delete. Most of these types of changes involve transient relationships or fetched properties.

Code for Context 1

First, let’s look at the context setter methods. Whenever other contexts save, we want to make sure our own context updates on their saves. Thus we add an addObserver to observe saves from other contexts. Whenever other contexts save, the message NSManagedObjectContextDidSaveNotification gets sent, and we capture it like so:

1 2 3 4

[[NSNotificationCenter defaultCenter] addObserver:self                                              selector:@selector(mergeChangesFromContext2:)                                                  name:NSManagedObjectContextDidSaveNotification                                                object:self.privateQueueContext2];

What this means is that whenever object self.privateQueueContext2 sends a message name NSManagedObjectContextDidSaveNotification, then let’s call custom method mergeChangesFromContext2.

Note that for the object parameter, if you can it to the sender of the notification such as self.privateQueueContext2, then we will then only be notified of self.privateQueueContext2’s events.

If we set to “nil” you will get all notification of this type (regardless who sent them).

In our particular case, we set the object parameter to context 2, so that we can be updated on whatever context 2 just did, or is doing.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

- (NSManagedObjectContext *)privateQueueContext {          // Returns the managed object context for the application (which is already bound to the persistent store coordinator for the application.)     if (_privateQueueContext != nil) {         return _privateQueueContext;     }          NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];     if (!coordinator) {         return nil;     }          //_managedObjectContext = [[NSManagedObjectContext alloc] init];          _privateQueueContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];     [_privateQueueContext setPersistentStoreCoordinator:coordinator];          //Whenever the notifiation <name> from <object> is sent, then we call the selector method     [[NSNotificationCenter defaultCenter] addObserver:self                                              selector:@selector(mergeChangesFromContext2:)                                                  name:NSManagedObjectContextDidSaveNotification                                                object:self.privateQueueContext2];               NSLog(@"PrivateQueueContext CREATED" );     return _privateQueueContext; }   ... ...

The custom method gets called whenever context 2 saves, because we as context 1, wants to merge changes from context 2 if and when context 2 does save. We do a simple check that if the notification is from context 2, then we simply have our context 1 merge via the method mergeChangesFromContextDidSaveNotification method:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

//CONTEXT 2 JUST SAVED, THUS TELL CONTEXT 1 TO MERGE CHANGES FROM CONTEXT 2 - (void)mergeChangesFromContext2:(NSNotification *)notification {          NSManagedObjectContext *savedContext = [notification object];     if (self.privateQueueContext == savedContext) return;          if (self.privateQueueContext2 == savedContext) {         NSLog(@"Merging changes from privateQueueContext2 to Context 1 via notification object'");                  if(((NSManagedObjectContext*)notification.object).persistentStoreCoordinator != self.persistentStoreCoordinator) {             NSLog(@"privateQueueContext2's persistentStoreCoordinator != self.persistenStoreCoordinator");             return;         }                  NSLog(@"CONTEXT 2 JUST SAVED, HENCE CONTEXT 1 MERGE CHANGES FROM CONTEXT 2");                  dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{             [self.privateQueueContext mergeChangesFromContextDidSaveNotification:notification];         });                       } }

Run the program, add your bulk of People object. Then Display them. You’ll see the first object which is 0th index.

reportOnAllPeopleToLog method called
2015-10-27 11:17:59.555 CoreData2[49227:5232602] ———— RESULTS FROM DATABASE ————
2015-10-27 11:17:59.556 CoreData2[49227:5232602] There are 10 number of entries so far
2015-10-27 11:17:59.556 CoreData2[49227:5232602] 0 —————-
2015-10-27 11:17:59.556 CoreData2[49227:5232602] firstName = remark: 1445969859.502338
2015-10-27 11:17:59.557 CoreData2[49227:5232602] lastName = 1445969859.502338
2015-10-27 11:17:59.557 CoreData2[49227:5232602] object address is: 0x7fd358d8f710
2015-10-27 11:17:59.558 CoreData2[49227:5232602] 1 —————-
2015-10-27 11:17:59.558 CoreData2[49227:5232602] firstName = remark: 1445969859.822105
2015-10-27 11:17:59.558 CoreData2[49227:5232602] lastName = 1445969859.822105
2015-10-27 11:17:59.559 CoreData2[49227:5232602] object address is: 0x7fd358d83d40
…
…
etc.

Press button Context 1, Change to Ricky
Press button Context 2, Change to Shirley
Press Context 2 save
Press Context 1 save.

You’ll then see that Context’s RICKY is the latest save

result:


reportOnAllPeopleToLog method called
2015-10-27 11:19:53.481 CoreData2[49227:5232602] ———— RESULTS FROM DATABASE ————
2015-10-27 11:19:53.481 CoreData2[49227:5232602] There are 10 number of entries so far
2015-10-27 11:19:53.481 CoreData2[49227:5232602] 0 —————-
2015-10-27 11:19:53.481 CoreData2[49227:5232602] firstName = RICKY
2015-10-27 11:19:53.481 CoreData2[49227:5232602] lastName = 1445969859.502338
2015-10-27 11:19:53.481 CoreData2[49227:5232602] object address is: 0x7fd358c31a90
2015-10-27 11:19:53.482 CoreData2[49227:5232602] 1 —————-
…
…
etc


The result is now correct. When context 2 saved Shirley, context 1 merged itself with context 2’s changes, and thus when our context 1 saves, it will see that the persistent store value and its snapshot value are both “Shirley”, and thus goes on to save its own changes of “Ricky”. Thus, after the save, we see that the value “Ricky” is reflected in the database.

Some Upkeep

However, this only applies for context 1 merging if and when context 2 saves. What if context 2 need to merge on what context 1 does? That means we have to do the same thing for context 2.

Also, what if we have x number of contexts? That means for whatever context n that’s saving, we just make sure all other contexts merge with the saving context.

Notice object is set to nil in order to observe NSManagedObjectContextDidSaveNotification messages from any object. Then in our mergeChanges custom method, we simply make all contexts merge with the saving context.

1 2 3 4

[[NSNotificationCenter defaultCenter] addObserver:self                                              selector:@selector(mergeChanges:)                                                  name:NSManagedObjectContextDidSaveNotification                                                object:nil];

and…

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

- (void)mergeChanges:(NSNotification *)notification {          NSManagedObjectContext *savedContext = [notification object];             if (self.privateQueueContext2 == savedContext) {         NSLog(@"context 2 just saved, thus, need to tell others to update");     }          if (self.privateQueueContext == savedContext) {         NSLog(@"context 1 just saved, thus, need to tell others to update");     }          NSLog(@"Merging changes from privateQueueContext2 to Context 1 via notification object'");          if(((NSManagedObjectContext*)notification.object).persistentStoreCoordinator != self.persistentStoreCoordinator) {         NSLog(@"privateQueueContext2's persistentStoreCoordinator != self.persistentStoreCoordinator");         return;     }          NSLog(@"CONTEXT 2 JUST SAVED, HENCE CONTEXT 1 MERGE CHANGES FROM CONTEXT 2");          dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{         [self.privateQueueContext mergeChangesFromContextDidSaveNotification:notification];         [self.privateQueueContext2 mergeChangesFromContextDidSaveNotification:notification];     });      }

Using the Queue and performing your edits and saves via blocks

Apple states:
[A context] assumes the default owner is the thread or queue that allocated it—this is determined by the queue that calls its init method. You should not, therefore, initialize a context on one queue then pass it to a different queue.

This means that in our custom setter method for a context, we create the context with an init to a concurrency queue type. This means default owner of privateQueueContext is the queue used via the init:

1 2 3 4 5

- (NSManagedObjectContext *)privateQueueContext { ... _privateQueueContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; .... }

Hence privateQueueContext and the init-ed queue are now pinned together. This pattern is thread confinement or isolation.

We created privateQueueContext with this queue, and must remember to always use privateQueueContext with this queue.

For example, say we have a task: “use privateQueueContext to get a Person object to manipulate and later save into Core Data”. We want to queue this task because we’re doing this 10,000 times and needs to be run on a background. We queue this task on privateQueueContext because privateQueueContext is what is involved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

-(BOOL)addBulkPeople {     NSLog(@"--------  ADD BULK PEOPLE -----------");          [self.privateQueueContext performBlock:^{         for(int i = 0; i < 10000; i++) {                      ......                          //insert new entry into core data environment             Person * aPerson = [NSEntityDescription insertNewObjectForEntityForName:@"Person"                                                              inManagedObjectContext:coreDataStack.privateQueueContext];                        //edit Persons Object                          [coreDataStack privateQueueContextOneSave];         }       }];          return TRUE; }

Notice we use privateQueueContext on all. If in the task of fetching the Object using privateQueueContext but queueing the task on say privateQueueContext2 (which has its own queue via an init), then we have “have violated thread confinement by exposing the MOC object reference to two queues. Simple. Don’t do it. Don’t cross the streams.” (http://stackoverflow.com/questions/4800889/what-does-apple-mean-when-they-say-that-a-nsmanagedobjectcontext-is-owned-by-the)

Part of the reason is because multiple queues process tasks concurrently. So whatever context data you are executing in queue A, may also be executed in queue B at the same time. If you were to confine tasks to its attached queue, then no context data will ever be shared because each task is processed one after another via FIFO.

furthermore