Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Ben Trumbull <email@hidden>
- Date: Wed, 16 Nov 2005 17:41:46 -0800
At 12:13 PM +1100 11/17/05, Lachlan Deck wrote:
where would you have the sharedEC refetch for newly inserted objects?
You can use objectsWithFetchSpecification() on the sharedEC for this purpose.
As for "when", that depends on when you'd like to make them available
to the rest of the application.
The ordering of the lock/unlocking is important and must not be changed.
I didn't think that the shared EC had to be locked from my reading of the API:
"In multithreaded applications, shared objects can be used safely by
many threads at once. Shared editing contexts use NSMultiReaderLocks
to maintain thread safety. The methods objectsWithFetchSpecification
bindObjectsWithFetchSpecification, faultForGlobalID, and
objectForGlobalID are thread safe..."
If you're working with shared objects in a regular EOEditingContext,
then you do not need to explicitly lock the shared context. EOF does
that for you.
Several people mentioned it was difficult to get multithreaded apps
to robustly handle changing shared objects. Updating shared objects
is done by working on not-shared objects and then relying on the
change notifications to sort things out.
Explicitly locking should address these problems by more strictly
ordering things. It also ensures that the thread making the changes
also owns the shared context and can update the shared context
immediately. Notifications are normally queued if the notifying
thread cannot get a lock.
But what does this little sentence mean?
" but the context must be locked before using any other shared context API."
It means only the methods explicitly documented to be thread safe are
self-locking. It also means, if you try to use an
EOSharedEditingContext like a regular EOEditingContext you've entered
the Land of Hurt.
Does this refer to the object store coordinator - seeing as EOF uses one?
I'm not sure what you're asking here.
--
-Ben
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden