• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: SharedEditingContext Write Locks?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SharedEditingContext Write Locks?


  • Subject: Re: SharedEditingContext Write Locks?
  • From: Ben Trumbull <email@hidden>
  • Date: Wed, 16 Nov 2005 15:45:11 -0800

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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: SharedEditingContext Write Locks?
      • From: Ian Joyner <email@hidden>
    • Re: SharedEditingContext Write Locks?
      • From: Dov Rosenberg <email@hidden>
    • Re: SharedEditingContext Write Locks?
      • From: Dov Rosenberg <email@hidden>
    • Re: SharedEditingContext Write Locks?
      • From: Lachlan Deck <email@hidden>
References: 
 >SharedEditingContext Write Locks? (From: Dov Rosenberg <email@hidden>)
 >Re: SharedEditingContext Write Locks? (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: EO_PK_TABLE and auto_increment
  • Next by Date: Re: SharedEditingContext Write Locks?
  • Previous by thread: Re: SharedEditingContext Write Locks?
  • Next by thread: Re: SharedEditingContext Write Locks?
  • Index(es):
    • Date
    • Thread