Same problem here..... 2.44 & mySql w InnoDb
We experienced something similar. In our case, it turned out to be an overflow of the JMS queue. When the JMS queue is full, the EJB sending the notification cannot deliver the JMS message, so it blocks. The clients that respond to the messages delivered by the JMS queue required a resource that was held by one the of message senders. So they blocked. Because of this, no slots become available in the JMS queue, so we experienced a nice deadlock.
If you have the same kind of deadlock, try to measure when it occurs: in our case, it occurred under heavy load and always with *exactly* the same number of transactions occurring before the deadlock.
Solution: seriously boost the number of JMS slots in the $jboss/conf/standardjboss.xml. See below for an example, you need to modify the 1000 field.
<container-name>Standard Message Driven Bean</container-name>
<!-- CMT -->
<!-- BMT -->
now the problem seems fixed at 80%
We still have a problem when, during a server long-time task, a different client makes a call on one EJB involved with this task.
Sometimes seems that the second client locks the EJB table when making the call so, when the first task needs to access the same EJB to store new data, the container immediately throws a deadlock exception and cmp attributes are not updated.
As soon as I can, I will provide a JBoss stack trace to add some info about it.
Thanks a lot for the help,