| |||
| |||
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Hi! 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? Why can't I find any equivalent of EOFetchSpecification.setRefreshesFetchedObjects() on NSFetchPredicate? I don't quite get the NSManagedObjectContext documentation on staleness. What's infinite staleness? Best Pierre ********************************************************************** This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender of this message. (email@hidden) This email message has been checked for the presence of computer viruses; however this protection does not ensure this message is virus free. Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu ********************************************************************** _______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/email@hidden This email sent to email@hidden
| Home | Archives | FAQ | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2007 Apple Inc. All rights reserved.
