Here goes the thread dump regarding the lock I was talking about.
The line closest to the top of the stack, regarding a "getStore" method, is
a call to the "MailSessionBean" that appears some lines below.


"PoolThread-4" prio=5 tid=0x0BD16F18 nid=0x578 in Object.wait()
[1100e000..1100fd8c]
        at java.lang.Object.wait(Native Method)
        - waiting on <0380CF00> (a
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock)
        at java.lang.Object.wait(Object.java:426)
        at
org.jboss.ejb.plugins.lock.BeanLockSupport.sync(BeanLockSupport.java:68)
        - locked <0380CF00> (a
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock)
        at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:199)
        at
org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownIntercept
or.java:172)
        at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
        at
org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:
380)
        at
org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContai
nerInvoker.java:301)
        at
org.jboss.ejb.plugins.local.StatefulSessionProxy.invoke(StatefulSessionProxy
.java:41)
        at $Proxy64.getStore(Unknown Source)
        at inocrea.ejb.mail.session.MailStoreBean.ejbActivate(Unknown
Source)
        at
org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.activateSession(St
atefulHASessionPersistenceManager.java:206)
        at
org.jboss.ejb.plugins.StatefulSessionInstanceCache.activate(StatefulSessionI
nstanceCache.java:83)
        at
org.jboss.ejb.plugins.StatefulHASessionInstanceCache.get(StatefulHASessionIn
stanceCache.java:115)
        at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:212)
        at
org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownIntercept
or.java:172)
        at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
        at
org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:
380)
        at
org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContai
nerInvoker.java:301)
        at
org.jboss.ejb.plugins.local.StatefulSessionProxy.invoke(StatefulSessionProxy
.java:41)
        at $Proxy62.recover(Unknown Source)
        at inocrea.ejb.mail.session.MailSessionBean.recover(Unknown Source)
        at inocrea.ejb.mail.session.MailSessionBean.ejbActivate(Unknown
Source)
        at
org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.activateSession(St
atefulHASessionPersistenceManager.java:206)
        at
org.jboss.ejb.plugins.StatefulSessionInstanceCache.activate(StatefulSessionI
nstanceCache.java:83)
        at
org.jboss.ejb.plugins.StatefulHASessionInstanceCache.get(StatefulHASessionIn
stanceCache.java:115)
        at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:212)
        at
org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownIntercept
or.java:172)
        at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
        at
org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:
380)
        at org.jboss.ejb.Container.invoke(Container.java:738)
        at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
        at
org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:99)
        at
org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxyHA.invoke(JRMPInvokerPr
oxyHA.java:148)
        at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108)
        at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77
)
        at
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80)
        at
org.jboss.proxy.ejb.StatefulSessionInterceptor.invoke(StatefulSessionInterce
ptor.java:117)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76)
        at $Proxy59.ensureAuthenticated(Unknown Source)
        at inocrea.web.webmail.model.JwmaSession.ensureAuthenticated(Unknown
Source)
        at
inocrea.web.webmail.control.JwmaController.doDispatchSessionActions(Unknown
Source)
        at inocrea.web.webmail.control.JwmaController.service(Unknown
Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
        at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandl
er.java:294)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
        at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext
.java:505)
        at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
        at org.mortbay.http.HttpServer.service(HttpServer.java:879)
        at org.jboss.jetty.Jetty.service(Jetty.java:460)
        at org.mortbay.http.HttpConnection.service(HttpConnection.java:770)
        at
org.mortbay.http.ajp.AJP13Connection.handleNext(AJP13Connection.java:257)
        at org.mortbay.http.HttpConnection.handle(HttpConnection.java:787)
        at
org.mortbay.http.ajp.AJP13Listener.handleConnection(AJP13Listener.java:204)
        at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
        at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454)







----- Original Message ----- 
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 01, 2003 9:49 PM
Subject: Re: [JBoss-user] ejbActivate() and concurrent calls on stateful
beans


> Probably, but the deadlock thread dump is needed to be sure.
>
> -- 
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
> Joao Clemente wrote:
>
> > I'm trying to use the following pattern to recover my ejb's after a
> > failover:
> > Each EJB checks the need for recovery inside "ejbActivate()".
> > If there is a need to recover, it eventually calls another EJB to get
some
> > value.
> >
> > I'm facing a deadlock situation here where I believe that it should
appear a
> > "concurrent calls on stateful beans" exception instead:
> >
> > EJB1 activates. He needs to recover and needs to call ejb2 to have a
certain
> > value.
> > EJB2 is passivated so EJB2 activates. He also needs to recover and needs
a
> > value that is in ejb1.
> > I find a deadlock occuring here, where I was expecting to obtain an
> > exception ("concurrent calls on stateful beans").
> >
> > Using this pattern with methods other than ejbActivate we get that
> > exception, so shouldn't it occur here aswell?
> >
> > ejb1 {
> >   ejbActivate() {
> >      ejb2.someMethod()
> >   }
> > }
> >
> > ejb2 {
> >   ejbActivate() {
> >      ejb1.someMethod()
> >   }
> > }
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to