• 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 17:41:46 -0800

At 12:13 PM +1100 11/17/05, Lachlan Deck wrote:
where would you have the sharedEC refetch for newly inserted objects?

You can use objectsWithFetchSpecification() on the sharedEC for this purpose.

As for "when", that depends on when you'd like to make them available to the rest of the application.

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.

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.

But what does this little sentence mean?
" but the context must be locked before using any other shared context API."

It means only the methods explicitly documented to be thread safe are self-locking. It also means, if you try to use an EOSharedEditingContext like a regular EOEditingContext you've entered the Land of Hurt.


Does this refer to the object store coordinator - seeing as EOF uses one?

I'm not sure what you're asking here. --

-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: Lachlan Deck <email@hidden>
References: 
 >SharedEditingContext Write Locks? (From: Dov Rosenberg <email@hidden>)
 >Re: SharedEditingContext Write Locks? (From: Chuck Hill <email@hidden>)
 >Re: SharedEditingContext Write Locks? (From: Ben Trumbull <email@hidden>)
 >Re: SharedEditingContext Write Locks? (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Newbie Question about Assistant request for URL
  • 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