Re: Tracking EC Locking Issues when using MultiECLockManager and LockErrorScreamerEditingContext
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: Mon, 19 May 2008 17:12:51 +1000
Hi Owen,
On 19/05/2008, at 1:41 PM, 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.
with regards,
--
Lachlan Deck
er.extensions.ERXApplication.useEditingContextUnlocker=true
er.extensions.ERXEC.defaultAutomaticLockUnlock=true
er.extensions.ERXEC.useSharedEditingContext=false
er.extensions.ERXEC.defaultCoalesceAutoLocks=true
_______________________________________________
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