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: Michelle Parker <email@hidden>
- Date: Wed, 21 May 2008 10:34:45 +1000
Hi Owen
We had a situation where awake was being called twice in a
WOComponent and the editingContext was being locked there.
This resulted in the editingContext being locked twice and then, of
course, sleep only unlocked it once, leaving it in a unrecoverable
deadlock.
We added a check to see if awake had already been called to prevent
the second awake lock occurring.
This may be not what you are experiencing, but it solved our problem.
HTH
mich
On 21/05/2008, at 8:08 AM, Chuck Hill wrote:
On May 18, 2008, at 8:41 PM, Owen McKerrow wrote:
Hi All,
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 ?
Don't expect it to be easy. Or were you beyond that point? :-)
That trace below looks like it is for the session's
defaultEditingContext. Some possible cases to look at:
1. Something is happening in sleep() such that super.sleep() is not
getting called.
2. Some exception is preventing sleep() from getting called
Offhand, I can't think of anything else that fits.
You can modify LockErrorScreamerEditingContext to log every single
lock and unlock. That can help you track down where the missing
operation is, though it can be a lot to read through.
13:26:40,676 !!! EC HashCode :13694334 editing context being
disposed with 1 locks.
13:26:40,677 !!! Most recently locked by:
java.lang.Throwable
at edu.uow.ris.framework.LockErrorScreamerEditingContext._trace
(LockErrorScreamerEditingContext.java:114)
at edu.uow.ris.framework.LockErrorScreamerEditingContext.lock
(LockErrorScreamerEditingContext.java:57)
at com.webobjects.appserver.WOSession._awakeInContext
(WOSession.java:717)
at com.webobjects.appserver.WOApplication.restoreSessionWithID
(WOApplication.java:1550)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatch
WithPreparedApplication(WOComponentRequestHandler.java:314)
at
com.webobjects.appserver._private.WOComponentRequestHandler._handleRe
quest(WOComponentRequestHandler.java:358)
at
com.webobjects.appserver._private.WOComponentRequestHandler.handleReq
uest(WOComponentRequestHandler.java:435)
at com.webobjects.appserver.WOApplication.dispatchRequest
(WOApplication.java:1306)
at Application.dispatchRequest(Application.java:353)
at com.webobjects.appserver._private.WOWorkerThread.runOnce
(WOWorkerThread.java:173)
at com.webobjects.appserver._private.WOWorkerThread.run
(WOWorkerThread.java:254)
at java.lang.Thread.run(Thread.java:613)
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:
40webobjectives.com.au
This email sent to email@hidden
_______________________________________________
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