• 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: Fri, 18 Nov 2005 11:11:59 -0800

At 11:38 PM +0100 11/17/05, David Teran wrote:
Now my question: if i am not really aware that i am changing such a shared eo, because a 'set' method in another (non shared) eo changes something in such a 'shared' eo, then i would normally -not- do this kind of locking because i simply do not know that i am changing a shared eo. So wouldn't it be recommended to do this kind of locking always?

You're not allowed to do that.

You must not make changes to shared EOs in an EC with a non-null shared context. You must not have bidirectional relationships between shared and unshared EOs. You must not have any relationships from a shared EO to an unshared EO.

EOs in a shared editing context can be pointer TO by regular EOs.

Another way of thinking about it is:
all the EOs in the EOSharedEditingContext must create a self contained object graph. If you start with any shared EO, there must not be any way to "reach" an unshared EO.


If EOs in regular ECs want to have references to pieces of that graph, that's fine. But unshared EOs do not get to participate in it.

AFAIK using sec works fine if the shared eos will -never- change in the same EOF stack, but as soon as they are changed and saved (ok, without this kind of locking) its quite likely to get a deadlock. I guess i will have to 'activate' this sec stuff again to make some checks.

After making sure you're not violating my paragraph #1 above, please file a bug with bugreport.apple.com. Please include a stack trace of all the threads.


You could also file a bug that it would sure be handy if EOF enforced by exceptions the restrictions I mentioned above.

Another issue: i wonder what the real benefit is. I guess its only that we do not have duplicated EOEnterpriseObject instance flying around, saving time and memory when generating EOs from snapshots.

Yes.

You could achieve some of the benefits by creating a regular EC with setRetainsRegisteredObjects to true, prepopulate it, and then stash it in a global or leak it. This way the EODatabase row cache will always have the rows cached (unless you invalidate) so faulting in these pseudo-shared objects will be fast.

On the other side i remember someone doing profiling with activated shared ec and the result was: for heavy EOF access using shared ec results in poorer performance because of lots of lock and unlocks (in the shared ec).

Yes. EOSharedEditingContexts are useful if you're memory bound. --

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

  • Prev by Date: Simple Newbie Question
  • Next by Date: MultiECLockManager
  • Previous by thread: Re: SharedEditingContext Write Locks?
  • Next by thread: Re: SharedEditingContext Write Locks?
  • Index(es):
    • Date
    • Thread