Re: locking problem
Re: locking problem
- Subject: Re: locking problem
- From: David Teran <email@hidden>
- Date: Tue, 21 Dec 2004 00:15:17 +0100
Hi,
OK, the locking stuff is not so complicated:
1) surround every lock unlock by a try finally statement if it occurs
in one method:
try {
ec.lock();
... some code ...
} finally {
ec.unlock();
}
This is important because ...some code... might raise an exception and
then the unlock() would be missing.
2) Keep in mind that resolving a fault might occur during
appendToResponse, this can happen for the following example:
try {
ec.lock();
users = EOUtilities.objectsForEntityNamed(ec, "Users");
} finally {
ec.unlock();
}
now if users is bound to a WORepetition's 'list' binding the the users
will be fetched during appendToResponse if they were a) never fetched
b) if they were fetched but the timestamplag from the ec is newer than
the one from the snapshot
so in this case the code above would result in EOF usage -without- a
lock, bad thing.
The only solution is to lock and unlock the ec, but when?
1) as above and additionally in appendToResponse:
public void appendToResponse(WOResponse r, WOContext c) {
try {
ec.lock();
super.appendToResponse(r, c);
} finally {
ec.unlock();
}
}
i cannot really recommend this, but it works in most cases.
2) using ERXEC from project wonder: this nice editingcontext factory
does all you need.
3) locking on creation or in session's awake, unlocking in session's
sleep method. This is more or less what the multilockmanager does.
regards, David
On 19.12.2004, at 23:50, Nathan Dumar wrote:
In reading a discussion thread about ERXEC recently, Anjo said that
ERXEC only locks during the "dangerous" operations, like save, fetch,
etc. So, that's what I'm doing now -- putting locks in the try block,
before any fetch or save, and unlocking right after, in the finally
block. From what I've read, this seems to be the best solution, but
I'm always open to learn more. If anyone has suggestions, ideas,
warnings, or whatever, please post.
_______________________________________________
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