Concurrent MOCs

  • Re-reading the documentation for concurrent managed object contexts in preparation for moving some of my slower DB work off the main thread.

    It's very clear that messages you send to the MOC must be inside performBlock: or performBlockAndWait:, so if I execute a fetch request or anything else with that MOC, a line of the form

    [ concurrentMOC doSomethingWith:something ]

    that must be inside a performBlock[AndWait]: call. This makes total sense. executeQuery is one of those calls which I do quite a bit. The documentation talks about "standard messages to send to the context".

    How about the objects which are then owned by the MOC, the managed objects? Do any messages sent to them, even a property or relationship lookup, need also to be in a performBlock: call on the MOC owning those objects? I thought about it and eventually decided, perhaps, if the data isn't there and they are faults, the MOC is going to have to do something to fill them and that something should surely be done on its thread. But I can't find that stated anywhere and if it's the case it massively complicates the code. Just getting one property from one managed object (which was handed to you and may be from a non-main-thread MOC) means accessing a property becomes

    id __block theProperty = nil;
    [ foo.managedObjectContext performBlockAndWait:^{
      theProperty = foo.property;
    } ];

    instead of just using foo.property directly.

    Or are MOC's smart enough to figure this out and fulfil their internal faults with the equivalent to performBlockAndWait: and only messages sent directly to the MOC need to be done inside a block?
  • On Jun 10, 2013, at 6:28 AM, Roland King <rols...> wrote:

    > How about the objects which are then owned by the MOC, the managed objects? Do any messages sent to them, even a property or relationship lookup, need also to be in a performBlock: call on the MOC owning those objects?

    For an NSManagedObjectContext using private queue concurrency, yes. The cardinal rule of Core Data is that virtually any interaction with a managed object other than memory management is also an interaction with its context.

    This is actually particularly true for property (attribute and relationship) access, because that can fire or traverse faults.

      -- Chris
previous month june 2013 next month
MTWTFSS
          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
Go to today