Re: SharedEditingContext Write Locks?
Re: SharedEditingContext Write Locks?
- Subject: Re: SharedEditingContext Write Locks?
- From: David Teran <email@hidden>
- Date: Thu, 17 Nov 2005 23:38:02 +0100
So if I do something like
ec.objectsWithFetchSpecification(....)
And the objects had been previously retrieved by the SharedEC -
would ec be
able to use them?
Yes. This is the pattern I recommend.
The shared objects will be pointer equal, no matter how many
regular ECs are using them. Setting the regular EC's shared
context to null allows you to fetch and change different working
copies of the EOs, just as EOF works with regular ECs.
OK, this was clear to me. But i 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;
}
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?
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.
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).
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.
regards, David
_______________________________________________
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