Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Karl <email@hidden>
- Date: Thu, 17 Nov 2005 22:42:06 -0500
Hmm..are we missing the fact that setting Both Side of the
Relationship is a convenience method? ie. if the relationship is
single sided into the SEC then no change occurs?
The golden rule is not to have any relationships from objects in the
SEC to other EOF objects outside of it.
If the relationship is one-sided (and the right way around) then it
will work just fine.
Karl
On 17-Nov-05, at 7:34 PM, Lachlan Deck wrote:
Hi there,
On 18/11/2005, at 9:38 AM, David Teran wrote:
have an additional question: If i am changing an EO which was
fetched into a SEC, i must do something like this according to a
previous mail from you:
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;
}
I'm still not certain that the shared ec needs locking (in theory
anyway). i.e., it's supposed to be thread safe and picks up changes
via notifications. From what I gather Ben is saying it seems that
this is a strategy to use if you want the changes available
immediately to all other ecs.
Now my question: if i am not really aware that i am changing such
a shared eo
The EOSharedEditingContext API rule of thumb: "It is possible to
modify shared objects while an application is running, but only
indirectly. A regular editing context can be created that doesn't
share objects by setting it's sharedEditingContext to null."
So, the basic rule of thumb will need to be (in an app making use
of the SEC) do not commit changes with an EC that knows about SEC.
i.e.,
EOEditingConext ec = new EOEditingContext();
EOUtilities.localInstance[s]OfObject[s](ec, ...);
But, according to
<http://developer.apple.com/documentation/LegacyTechnologies/
WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/
DeltaDoc/EOF.html#CBGCHAIA>
"With 4.5, you can fetch read-only objects such as FeeTypes into a
shared editing context once, when an application starts, and all
the application's sessions can share those objects. For example,
***objects in any session can create relationships*** to the shared
FeeType objects even though the FeeTypes are in a different editing
context from the source objects. Using previous releases, you would
have to make local copies of the read-only FeeTypes in each of the
editing contexts that use them."
I shall have to read some more to clarify this. i.e., setting Both
Sides Of Relationship would obviously still dictate that the shared
eo needs refreshing - and therefore saved via a non-shared ec...
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?
Don't think this would be good.
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.
The deadlock would be a bug if it did happen. The changes to
existing shared eos by a non-SEC committed to the database are
meant to be picked up via notifications by the SEC automatically
(unless they're newly inserted eos -> refetch is required).
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.
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).
Maybe some up-to-date profiling by someone could help clarify this.
Well, i will have to make tests to find answers and i will
definitely check this kind of locking, i've never seen such a
recommendation before.
shall be interesting to see your results.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
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