• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unable to release locks when using MultiECLockManager
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to release locks when using MultiECLockManager


  • Subject: Re: Unable to release locks when using MultiECLockManager
  • From: Art Isbell <email@hidden>
  • Date: Tue, 29 Apr 2008 17:08:36 -1000

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.


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.

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?

Aloha,
Art

_______________________________________________
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


  • Follow-Ups:
    • Re: Unable to release locks when using MultiECLockManager
      • From: Chuck Hill <email@hidden>
    • Re: Unable to release locks when using MultiECLockManager
      • From: Owen McKerrow <email@hidden>
References: 
 >Unable to release locks when using MultiECLockManager (From: Owen McKerrow <email@hidden>)
 >Re: Unable to release locks when using MultiECLockManager (From: Owen McKerrow <email@hidden>)
 >Re: Unable to release locks when using MultiECLockManager (From: Art Isbell <email@hidden>)
 >Re: Unable to release locks when using MultiECLockManager (From: Owen McKerrow <email@hidden>)
 >Re: Unable to release locks when using MultiECLockManager (From: Art Isbell <email@hidden>)
 >Re: Unable to release locks when using MultiECLockManager (From: Owen McKerrow <email@hidden>)

  • Prev by Date: Re: Unable to release locks when using MultiECLockManager
  • Next by Date: Re: Unable to release locks when using MultiECLockManager
  • Previous by thread: Re: Unable to release locks when using MultiECLockManager
  • Next by thread: Re: Unable to release locks when using MultiECLockManager
  • Index(es):
    • Date
    • Thread