• 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: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext


  • Subject: Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
  • From: Lachlan Deck <email@hidden>
  • Date: Tue, 20 May 2008 10:41:38 +1000

On 20/05/2008, at 9:29 AM, Owen McKerrow wrote:

In an effort to track down my locking issues I implemented the LockErrorScreamerEditingContext but unfortunately its not going to be as useful as I had hoped. I changed my MultiECLockManager to use a LockErrorScreamerEditingContext but of course this means that every lock will come from it, so when I get errors like the one below, the original stack trace that it prints out will always be from WOSession._awakeInContext.


So does anyone have any other suggestions as to how I go about tracking down where this mismatched lock is coming from ?

A bit of a tangent, but I believe you mentioned that you're migrating to Wonder recently. So, as ERXEC handles locking automatically (with the correct properties defined) you might want to limit your manual locking/unlocking to background/long-response threads. ERXEC prints out an error log if an ec locking mismatch occurred.


er.extensions.ERXApplication.useEditingContextUnlocker=true
er.extensions.ERXEC.defaultAutomaticLockUnlock=true
er.extensions.ERXEC.useSharedEditingContext=false
er.extensions.ERXEC.defaultCoalesceAutoLocks=true

Unfortunately its not this project thats going to Wonder ( it is in fact a brand new project that we are starting to use wonder on). Currently is not an option to convert the current project which is causing the problem over to Wonder. Although I do have to ask, how much "wonderizing" would I have to do to just get the ERXEC portion of Wonder into a non wonder app ?

Not a lot really... + ERExtensions + ERJars + extend ERXApplication + extend ERXSession + use ERXEC.newEditingContext()

As part of implementing the LockErrorScreamerEditingContext I went back through and removed all manual locks() and unlocks(). So in theory the MultiECLockManager is now managing all the locks, with every EC being created through the MultiECLockManager newEditingContext method. So its somewhat worrying that any problems with locking are occuring, but I'll keep digging.

Where are they happening? Long-responses? Any more info?

Any other ideas out there ?

with regards, --

Lachlan Deck
_______________________________________________
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: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
      • From: Lachlan Deck <email@hidden>
References: 
 >Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext (From: Owen McKerrow <email@hidden>)
 >Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext (From: Lachlan Deck <email@hidden>)
 >Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext (From: Owen McKerrow <email@hidden>)

  • Prev by Date: Re: Deployment error on start up
  • Next by Date: Re: ExistsInRelationshipQualifier
  • Previous by thread: Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
  • Next by thread: Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
  • Index(es):
    • Date
    • Thread