Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Dov Rosenberg <email@hidden>
- Date: Wed, 16 Nov 2005 22:11:13 -0500
- Thread-topic: SharedEditingContext Write Locks?
Those are some very good pieces of information. We have passed
SharedEditingContexts into methods that expect regular EditingContexts in a
lot of places. Here is an example:
We used to pass a SharedEditingContext into a method so we could use it like
userList = EOUtilities.objectsWithQualifierFormat(ec, "UserInformation",
"login = %@ AND ownerSite = %@", args);
Where ec was our SharedEditingContext.
We changed the code to do something like this instead:
fetchedRecords = ec.objectsWithFetchSpecification(fetchSpec);
Where ec is our SharedEditingContext. Is that the correct usage?
Is it safe to assume that if the SharedEditingContext does not contain the
data it will retrieve it. And if it does contain the data that it will use
it instead of re-fetching from the DB?
What is the purpose of the "Share all objects" checkboxes in the EOEntity in
EOModeler? Is it related to the "Cache objects" check box? Does EOF fetch
these things into the SharedEditingContext automatically?
We have a bunch of data that is static (lookup codes, etc) that are used in
relationships to other EOs that are not static. Can we fetch the lookupCodes
into the SharedEditingContext and make use of them in the regular editing
contexts?
Thanks again for all of your help. Hopefully other people have learned as
much as we have. Its amazing that even after using WebObjects since 1997 I
am still finding out subtle details like this. What a great product!!
On 11/16/05 6:45 PM, "Ben Trumbull" <email@hidden> wrote:
> 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.
_______________________________________________
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