K.
Here's the secret:
EOSharedEditingContexts are NOT EOEditingContexts.
They are only for use as an argument to setSharedEditingContext() and
their own explicit API.
They work best by using their API to fetch objects you wish to share
into the context, and then creating real EOEditingContexts and having
them use that shared context.
This paradigm works well as it makes dealing with shared contexts
entirely the problem of EOEditingContext, instead of yours.
You should NOT pass an EOSharedEditingContext to a method expecting a
regular EOEditingContext. Personally, I would NEVER do this, but
there are a few things that will work anyway, and if your app ain't
broke ...
You should only ever use the lock(), unlock(), or tryLock() methods
on EOSharedEditingContext.
I'm not sure why the lockForReading(), lockForWriting(),
suspendReaderLocks(), etc methods are public. These additional
locking methods are exclusively for the use of EOEditingContext to
properly interact with its shared context. They are impossible for
you to use correctly. Use the standard methods declared in the
NSLocking interface.
The crux of the issue here is that EOSharedEditingContext uses
implementation inheritance from EOEditingContext instead of
composition.
Seriously, EOSharedEditingContext is not a subclass of EOEditingContext.
At 12:59 PM -0800 11/14/05, Chuck Hill wrote:
See David's answer. My opinion on the Shared EC is to avoid it like
the plague if you plan on concurrency.
All known issues involving deadlocks with Shared ECs should be
resolved now (fixed sometime like 5.2.3)
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;
}
The ordering of the lock/unlocking is important and must not be changed.
--
-Ben
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
