CMP + RequiresNew = ApplicationDeadlock
morgan Sep 17, 2002 5:45 PMHi, I'm relatively new to JBoss and J2EE, and I'm currently running into a
problem with the "RequiresNew" transaction attribute. I've looked through
the forums, and have been going through Dain's JBossCMP documentation,
but I've yet to stumble across what might be causing my problem ... an
application deadlock due to the current thread already having a lock in a
different transaction. At the end of this message is (what I believe) to be
the relevant portion of the stack trace ... and if anyone would like more info,
I'd be more than happy to provide it.
What I have is an entity bean, "KeyFactory" which exposes one method and
I'm setting the transaction attribute for that method to "RequiresNew" by using
an XDoclet tag like so:
[pre]
@ejb:transaction type="RequiresNew"
[/pre]
which appears to generate the right thing in "ejb-jar.xml":
[pre]
<container-transaction >
<ejb-name>KeyFactory</ejb-name>
<method-intf>Local</method-intf>
<method-name>incrementKeyBy</method-name>
<method-params>
<method-param>int</method-param>
</method-params>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
[/pre]
No other transaction attributes are set, and (in my test case) this method,
"incrementKeyBy", is only being accessed once via a session bean which
is only called once. Oh, and if I remove the transaction attribute (or set it to
"Required") it works just fine. Currently, I'm using JBoss 3.0.2 and PostgreSQL 7.2.1
(thoughI had the same problem with Hypersonic).
Any help, or pointers to relevant documentation would be most appreciated
(I'm going a little crazy here).
Thanks,
Paul
p.s., I initially posted this to message to "EJB/JBoss", but I wasn't sure if that
was the right forum so I've cross-posted it here. I apologize if that's a major
faux pas, but I'm getting increasingly desperate.
[pre]
10:34:21,652 ERROR [STDERR] Caused by: org.jboss.ejb.plugins.lock.ApplicationDeadlockException: Application deadlock detected: Current thread already has tx lock in different transaction.
at org.jboss.ejb.plugins.lock.BeanLockSupport.deadlockDetection(BeanLockSupport.java:182)
at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.waitForTx(QueuedPessimisticEJBLock.java:283)
at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.doSchedule(QueuedPessimisticEJBLock.java:189)
at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.schedule(QueuedPessimisticEJBLock.java:140)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:103)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:255)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203)
at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:301)
at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
[/pre]