• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData: Data freshness vs. multithreading
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData: Data freshness vs. multithreading


  • Subject: Re: CoreData: Data freshness vs. multithreading
  • From: mmalcolm crawford <email@hidden>
  • Date: Tue, 3 May 2005 09:22:48 -0700


On May 3, 2005, at 8:14 AM, <email@hidden> <email@hidden> wrote:
I am currently working on a multithreaded CoreData application: The UI creates tasks on the main thread. Several worker threads pick up the tasks to process them. This may in turn lead to tasks to be performed by a third type of thread.
All three threads read and write to the same data store. Mostly no thread has uncommitted changes lingering for long.
I made the choice of having one managed object context for each thread. All set ontop of a shared object store coordinator. I see no way of doing it differently or else I would have to block all threads as long as one of them has uncommited changes.
I was hoping for the contexts to be notified of changes made in the other contexts. By default EOF would merge changes in this setup. It appears that CoreData just lets the data go stale which causes the next save to fail with an optimistic locking exception. While this is a behavior I have whished for in EOF it happens to be exactly the one I do not need in my current CoreData application. Actually I put quite some effort to simulating such behaviour in EOF. Odd, isn't it.
Should I listen to notifications from other managed object contexts and refresh objects one by one?


It's not clear what you actually want to do? Do you want to simply overwrite the updated data, or do you want to ensure that you have refreshed values in all the contexts? If the former, then you should be able to simply set a different merge policy (say, to NSMergeByPropertyStoreTrumpMergePolicy). If the latter, then yes you can listen for the relevant notifications.

Why can't I find any equivalent of EOFetchSpecification.setRefreshesFetchedObjects() on NSFetchPredicate?

Because that's not a feature provided by Core Data.

I don't quite get the NSManagedObjectContext documentation on staleness. What's infinite staleness?

A staleness interval of 0 is treated as an infinite length of time instead of zero.

mmalc

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CoreData: Data freshness vs. multithreading
      • From: Pierre Bernard <email@hidden>
References: 
 >CoreData: Data freshness vs. multithreading (From: <email@hidden>)

  • Prev by Date: Re: SearchKit and Spotlight
  • Next by Date: Re: Tiger documentation update
  • Previous by thread: CoreData: Data freshness vs. multithreading
  • Next by thread: Re: CoreData: Data freshness vs. multithreading
  • Index(es):
    • Date
    • Thread