Re: SharedEditingContext Write Locks?
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