Re: Unable to release locks when using MultiECLockManager
Re: Unable to release locks when using MultiECLockManager
- Subject: Re: Unable to release locks when using MultiECLockManager
- From: Owen McKerrow <email@hidden>
- Date: Wed, 30 Apr 2008 12:47:37 +1000
On 30/04/2008, at 12:07 PM, Art Isbell wrote:
On Apr 29, 2008, at 3:25 PM, Owen McKerrow wrote:
public void sleep()
{
// Need to check as this gets called after terminate() when
logging out
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
super.sleep();
}
Hmm, the version of MultiECLockManager that I use doesn't
implement isLocked(), so I don't know what isLocked()
accomplishes. The only public methods are lock(), unlock(),
registerEditingContext(), and unregisterEditingContext(), and I
never send a MultiECLockManager object an unregisterEditingContext
() message (it's not necessary).
I remember discussing MultiECLockManager on list last year with chuck
Hill ( http://lists.apple.com/archives/Webobjects-dev/2007/Apr/
msg00609.html ) who pointed out that he'd tweaked MultiECLockManager
inside his GVCWOExtensions framework. So thats where this version
comes from.
Also, in the MultiECLockManager that I use, lock() and unlock()
are synchronized methods, so I don't understand why you are
invoking unlock() in a synchronized block.
public void terminate()
{
// Need to make sure this is unlocked so that editing
contexts nested in the defaultEditingContext
// don't hold locks on it when it gets disposed
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
super.terminate();
}
The header in my version of MultiECLockManager makes no mention of
sending a MultiECLockManager object an unlock() message in
Session.terminate(), so I don't do this. However, if you do this
and there's no matching lock() invocation, MultiECLockManager will
throw an exception (maybe MultiECLockManager.isLocked() would
prevent this from occurring). You're not catching this exception
in terminate() and aren't invoking super.terminate() in a finally
block, so if an exception is thrown, super.terminate() won't be
invoked which can cause nasty problems.
So at minimum I should shift this into a try{} catch{} block ?
Aloha,
Art
Here is a copy of the MultiECLockManager.java file....
Attachment:
MultiECLockManager.java
Description: Binary data
_______________________________________________
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