On May 20, 2008, at 11:23 PM, Owen McKerrow wrote:
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
._dispatchWithPreparedApplication(WOComponentRequestHandler.java:314)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._handleRequest(WOComponentRequestHandler.java:358)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
.handleRequest(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
._dispatchWithPreparedApplication(WOComponentRequestHandler.java:329)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._handleRequest(WOComponentRequestHandler.java:358)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
.handleRequest(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.
Ah. Man, my memory is getting bad. It is a bug in WO. Fixed, I
believe in some flavor of 5.4. It is caused by your logout function
calling session().terminate() during the RR loop. You can try
session().setTimeOut(1) instead.
Chuck
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
._dispatchWithPreparedApplication(WOComponentRequestHandler.java:
314)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
._handleRequest(WOComponentRequestHandler.java:358)
at
com
.webobjects
.appserver
._private
.WOComponentRequestHandler
.handleRequest(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
--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
