Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: David Teran <email@hidden>
- Date: Fri, 18 Nov 2005 21:45:30 +0100
Hi Ben,
thanks, this was very helpful. I now have a better understanding
about this sec stuff and if i find time i will make some tests.
Regards, David
Am 18.11.2005 um 20:11 schrieb Ben Trumbull:
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