Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Lachlan Deck <email@hidden>
- Date: Thu, 17 Nov 2005 12:57:08 +1100
Hi there,
On 17/11/2005, at 12:41 PM, Ben Trumbull wrote:
At 12:13 PM +1100 11/17/05, Lachlan Deck wrote:
where would you have the sharedEC refetch for newly inserted objects?
As for "when",
That's what I meant...
that depends on when you'd like to make them available to the rest
of the application.
I meant: within you're lock/unlock scenario.
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.
Yep, that was my understanding.
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.
I suppose this depends on how immediate the changes need to be seen.
with regards,
--
Lachlan Deck
_______________________________________________
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