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: Owen McKerrow <email@hidden>
- Date: Wed, 21 May 2008 16:23:19 +1000
Hi Chuck,
The extra lock is coming from the _awakeInContext of the session.
java.lang.Throwable
at edu.uow.ris.framework.LockErrorScreamerEditingContext._trace
(LockErrorScreamerEditingContext.java:117)
at edu.uow.ris.framework.LockErrorScreamerEditingContext.lock
(LockErrorScreamerEditingContext.java:59)
at com.webobjects.appserver.WOSession._awakeInContext(WOSession.java:
717)
at com.webobjects.appserver.WOApplication.restoreSessionWithID
(WOApplication.java:1550)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatchWit
hPreparedApplication(WOComponentRequestHandler.java:314)
at
com.webobjects.appserver._private.WOComponentRequestHandler._handleReque
st(WOComponentRequestHandler.java:358)
at
com.webobjects.appserver._private.WOComponentRequestHandler.handleReques
t(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)
And the ec is trying to be disposed of from the _sleepInContext
java.lang.Throwable
at edu.uow.ris.framework.LockErrorScreamerEditingContext._trace
(LockErrorScreamerEditingContext.java:117)
at edu.uow.ris.framework.LockErrorScreamerEditingContext.goodbye
(LockErrorScreamerEditingContext.java:93)
at edu.uow.ris.framework.LockErrorScreamerEditingContext.dispose
(LockErrorScreamerEditingContext.java:100)
at com.webobjects.appserver.WOSession._sleepInContext(WOSession.java:
729)
at com.webobjects.appserver.WOApplication.saveSessionForContext
(WOApplication.java:1514)
at
com.webobjects.appserver._private.WOComponentRequestHandler._dispatchWit
hPreparedApplication(WOComponentRequestHandler.java:329)
at
com.webobjects.appserver._private.WOComponentRequestHandler._handleReque
st(WOComponentRequestHandler.java:358)
at
com.webobjects.appserver._private.WOComponentRequestHandler.handleReques
t(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)
Here is my Session's sleep and terminate methods :
public void sleep()
{
// Need to check as this gets called after terminate() when logging
out
try {
synchronized (ecLockManager)
{
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
}
finally {
super.sleep();
}
}
/**
* Unlock lock manager and diagnostic messages.
*/
public void terminate()
{
// Need to make sure this is unlocked so that editing contexts
nested in the defaultEditingContext
// don't hold locks on it when it gets disposed
try {
synchronized (ecLockManager) {
if (ecLockManager().isLocked())
{
ecLockManager().unlock();
}
}
}
finally {
super.terminate();
}
}
And just for good measure heres the constructor :
public Session() throws Exception
{
super();
log.info("\tSession has been created.\t" + sessionID());
numAccessInLastMinute = 1;
timeSinceLastCalled = new NSTimestamp();
ecLockManager = new MultiECLockManager();
setDefaultEditingContext(new LockErrorScreamerEditingContext());
}
I don't understand why the _sleepInContext is disposing of the ec
without the call to unlock it.
Owen McKerrow
WebMaster, emlab
Ph : +61 02 4221 5517
http://emlab.uow.edu.au
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
"I like the way this project has somehow, against all common sense,
got itself made."
- Peter Jackson, "The Lord of The Rings"
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:
This email sent to email@hidden