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: Tue, 29 Apr 2008 22:09:56 -0700
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.
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 ?
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).
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.
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