Re: CoreData: Data freshness vs. multithreading
Re: CoreData: Data freshness vs. multithreading
- Subject: Re: CoreData: Data freshness vs. multithreading
- From: Pierre Bernard <email@hidden>
- Date: Tue, 3 May 2005 20:15:36 +0200
Thanks Malcolm.
What I want is fresh data in all contexts. That is a behavior like
what EOF produces by the means of
ObjectsChangedInObjectStoreNotification.
I guess I'll go for listening for
NSManagedObjectContextDidSaveNotification and update local objects to
match.
Funny how I wish CoreData to keep all contexts fresh whereas I would
love EOF to behave like all contexts were on different stacks: fail
on save rather than merge. Oh well.
BTW, what's the word on locking NSManagedObjectContext in a
multithreaded environment? Same policy as for EOEditingContext?
Pierre
On May 3, 2005, at 6:22 PM, mmalcolm crawford wrote:
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
_______________________________________________
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