jboss/mysql cmp deadlock?

M

Michael Lim

hi folks,

has anyone run into ejb cmp deadlock with jboss/mysql? i can
reproduce this fairly easily by simply clicking on various links that
i know will access the database as a single user.

i've heard of turning off method transaction, or changing the CMP
entity bean commit option to commit-option "A". would like to know if
these are the only available options to tune this, or there's other
proper workaround or config tuning for this to avoid this deadlock.

the app i have is a very straightfoward application, and there's no
need for transactions, and currently jboss is the only entry point to
mysql to modify data.

i'm running jboss 3.2.3 with mysql 4.0.18.

here's part of my deadlock exception/stack trace.

thank you all very much for any help or info in advance.

michael lim
(e-mail address removed)

2004-09-23 14:37:01,025 ERROR [com.myapp.action.ShowGBParentAction]
org.jboss.util.deadlock.ApplicationDeadlockExceptionexception caught:
org.jboss.util.deadlock.ApplicationDeadlockException: Application
deadlock detected, resource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@21cf9c,
bean=User, id=2D0F93A70A0A0A01019829A918E37D02, refs=2,
tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=gb-app-srv01//1635,
BranchQual=], synched=Thread[TP-Processor2,5,jboss], timeout=5000,
queue=[], holder=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1633, BranchQual=],
waitingResource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@1c5130a,
bean=User, id=B06A31EE0A0A0A01005911710AE8D2EC, refs=2,
tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=gb-app-srv01//1633,
BranchQual=], synched=null, timeout=5000, queue=[TXLOCK
waitingTx=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1635, BranchQual=] id=0
thread=Thread[TP-Processor8,5,jboss] queued=true],
waitingResourceHolder=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1633, BranchQual=]
org.jboss.util.deadlock.ApplicationDeadlockException: Application
deadlock detected, resource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@21cf9c,
bean=User, id=2D0F93A70A0A0A01019829A918E37D02, refs=2,
tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=gb-app-srv01//1635,
BranchQual=], synched=Thread[TP-Processor2,5,jboss], timeout=5000,
queue=[], holder=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1633, BranchQual=],
waitingResource=org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock@1c5130a,
bean=User, id=B06A31EE0A0A0A01005911710AE8D2EC, refs=2,
tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=gb-app-srv01//1633,
BranchQual=], synched=null, timeout=5000, queue=[TXLOCK
waitingTx=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1635, BranchQual=] id=0
thread=Thread[TP-Processor8,5,jboss] queued=true],
waitingResourceHolder=TransactionImpl:XidImpl [FormatId=257,
GlobalId=gb-app-srv01//1633, BranchQual=] at
org.jboss.util.deadlock.DeadlockDetector.deadlockDetection(DeadlockDetector.java:48) at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(QueuedPessimisticEJBLock.java:301) at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(QueuedPessimisticEJBLock.java:236) at
org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(QueuedPessimisticEJBLock.java:183) at
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:85) at
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:54) at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267) at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489) at
org.jboss.ejb.Container.invoke(Container.java:700) at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375) at
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38) at
$Proxy82.getProviderrating(Unknown Source) at
com.myapp.serviceProviders.ServiceProviderManagerBean.getProviderRating(ServiceProviderManagerBean.java:309) at
com.myapp.serviceProviders.ServiceProviderManagerBean.getRating(ServiceProviderManagerBean.java:381) at
sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:324) at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683) at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267) at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at
org.jboss.ejb.Container.invoke(Container.java:700) at
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:375) at
org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke(StatelessSessionProxy.java:83) at
$Proxy106.getRating(Unknown Source) at
com.myapp.directories.DirectoryManagerBean.getGBProviderRating(DirectoryManagerBean.java:322) at
com.myapp.directories.DirectoryManagerBean.getGBProviderRatings(DirectoryManagerBean.java:816) at
sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:324) at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683) at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185) at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:267) at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128) at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:118) at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191) at
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) at
org.jboss.ejb.Container.invoke(Container.java:700) at
sun.reflect.GeneratedMethodAccessor115.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
java.lang.reflect.Method.invoke(Method.java:324) at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at
org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:101) at
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90) at
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) at
....
....
 
C

chunnu

when EJBs do load or store operations, they will lock the database in some
levels. If one ejb needs to lock two resources and it gets one, but
another ejb requires those two resources but it gets another. Then they
are waiting for another to release the resource locked by another. The
exception will occur if the time is out.
Maybe you should check the code to prevent those things from happening
 
C

chunnu

when EJBs do load or store operations, they will lock the database in some
levels. If one ejb needs to lock two resources and it gets one, but
another ejb requires those two resources but it gets another. Then they
are waiting for another to release the resource locked by another. The
exception will occur if the time is out.
Maybe you should check the code to prevent those things from happening
 
C

chunnu

when EJBs do load or store operations, they will lock the database in some
levels. If one ejb needs to lock two resources and it gets one, but
another ejb requires those two resources but it gets another. Then they
are waiting for another to release the resource locked by another. The
exception will occur if the time is out.
Maybe you should check the code to prevent those things from happening
 
H

Heiko W. Rupp

chunnu said:
Maybe you should check the code to prevent those things from happening
Click to expand...

Jboss also offers the "Instance per Tx" container configuration.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Transaction Error due to whether JBoss or SQL Server Driver 0
Unable to passivate due to ctx lock warning on JBoss 4.0.2 0
JBOSS problems - URGENT 4
JBOSS and JMS pb 0
JBoss EJB MessageContext Exception 0
problem with lomboz tutorial 0
EJB3 and JBoss 4.0.4 GA 8
JBoss: Error instantiating org.apache.jasper.servlet.JspServlet 0

Members online

No members online now.
Total: 37 (members: 0, guests: 37)
Robots: 331

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,009
Latest member
GidgetGamb

Latest Threads

Top