Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Lachlan Deck <email@hidden>
- Date: Thu, 17 Nov 2005 12:13:31 +1100
Hi there,
On 17/11/2005, at 10:45 AM, Ben Trumbull wrote:
People successfully use shared ECs in concurrent apps, although
updating shared objects is very difficult to do correctly. I've
seen it done by taking a large granularity lock in the request
handler. However, the following approach *should* work, and be less
drastic than that sledgehammer:
regularEC = new EOEditingContext();
regularEC.lock();
try {
regularEC.setSharedEditingContext(null);
// fetch or fault the currently shared objects to update into
regularEC
// update the ex-shared objects in regularEC
sharedEC.lock();
objectStoreCoordinator.lock();
try {
regularEC.saveChanges();
} finally {
objectStoreCoordinator.unlock();
sharedEC.unlock();
}
} finally {
regularEC.unlock();
regularEC = null;
}
where would you have the sharedEC refetch for newly inserted objects?
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..."
...and...
"Since shared editing contexts listen for
ObjectsChangedInStoreNotifications, the shared editing context
updates when it learns that an object was modified. <...> However, to
register newly inserted objects in the shared editing context, it
should be refetched."
But what does this little sentence mean?
" but the context must be locked before using any other shared
context API."
Does this refer to the object store coordinator - seeing as EOF uses
one?
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