Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: Lachlan Deck <email@hidden>
- Date: Fri, 18 Nov 2005 11:34:30 +1100
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:
This email sent to email@hidden