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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
