Re: EOSharedEditingContext question
Re: EOSharedEditingContext question
- Subject: Re: EOSharedEditingContext question
- From: Travis Britt <email@hidden>
- Date: Thu, 3 Feb 2005 22:33:34 -0500
On Feb 3, 2005, at 1:02 PM, Dov Rosenberg wrote:
In cases where we are going to modify data that has been retrieved
into the shared context, we create a new editing context and make the
changes and save. We lock both the shared and the regular context when
we do.
Chuck is right, no need to lock the shared editing context. It locks
itself. The 5.2.3 API docs are pretty decent for
EOSharedEditingContext:
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, but the context must be locked
before using any other shared context API.
(Also note that a shared editing context has both reader and writer
locks, should locking become necessary.)
A shared context registers for ObjectsChangedInStoreNotifications, and
it will refault an EO that has changed (assuming the EO was moved to a
regular editing context and modified.)
I used the shared context heavily on a project last year and was rather
pleased with the results. (No nasty bugs or explosions, highly
concurrent environment, 5.2.3.)
tb
_______________________________________________
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