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: Chuck Hill <email@hidden>
- Date: Wed, 30 Apr 2008 20:27:44 -0700
On Apr 29, 2008, at 10:48 PM, Owen McKerrow wrote:
On 30/04/2008, at 3:09 PM, Chuck Hill wrote:
On Apr 29, 2008, at 8:08 PM, Art Isbell wrote:
On Apr 29, 2008, at 4:47 PM, Owen McKerrow wrote:
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.
Ah, well it's not identical to the original version which is what
I'm using, so I'll let Chuck comment.
Jon and I had different ideas on how we wanted to integrate this
functionality into our applications. I made some changes to
support what I wanted. The basic code should be the same. We have
used this class in all of the apps we have written for some years
now. We never see the error that Owen is seeing. Thus, I suspect
the origin of the problem lies in his code.
I have no doubt it is : )
Theoretically, the condition that would result in unlock() being
invoked should be prevented by the isLocked() test, so an uncaught
exception may be unlikely. But I always include super.terminate()
in a finally clause because of the importance of it being invoked.
Amen. A better approach than my try...catch (Throwable).
OK how do I add this then ? i.e. how do I deal with any exceptions
that may be caused inside the try. My initial approach ( see below )
has the obvious problem ( ohh for some sleep and its only 3:30 in
the afternoon ) of "Unreported exception java.lang.Exception; must
be caught or declared to be thrown".
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
try {
synchronized (ecLockManager) {
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
} catch ( Exception ex ) {
throw ex;
}
finally {
super.terminate();
}
}
Your original problem appears to be caused by your code not
unlocking an editing context somehow. You've found a couple of
editing contexts that weren't being manually locked/unlocked
inappropriately. Might this have caused the Finalizer problem?
That is my suspicion also. Some other, previous exception left a
locked EC hanging around. When it got garbage collected, the
errors that Owen is seeing are the result.
So I take it from that statement that I will need to track down any
exceptions that are being made and not handled correctly ?
Yes, at least confirm that they will still result in any related,
locked editing context being unlocked.
Im willing to "donate" this problem to your "Best pratices" session
at WOWODC Chuck, so that you can give us a real life example ; )
:-)
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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