You should adjust your transaction timeout to solve this problem in conf/jboss-service.xml (default is 300 ms). This timeout must be higher than the max time for a MDB (or EJB) to be processed. Below it is set to 5 minutes.
<mbean code="org.jboss.tm.TransactionManagerService" name="jboss:service=TransactionManager" xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml"> <attribute name="TransactionTimeout">300000</attribute> <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends> </mbean>
Thanks, I'll try that.
In fact my main mistake is to have left my MDB with a Required transaction type. It does not need to be transactional by itself : I also changed the demarcation. Session beans below in the call chain are transactional and make shorter transactions.
I still have the problem, although I increased the time-out, and removed the useless top transaction.
JBoss will just stop doing anything. I don't think I have a deadlock anywhere, and I have the problem in two instances of JBoss 3.2.5. One is running with MySQL and with MDBs, the other has Oracle and the entry point is just a session bean. The common point is that it occurs as I am updating thousands of objects (I make the updates in intermediate size transactions, the top method has "NotSupported", and calls a "Required" method that updates a batch of objects).
I am using Standard CMP 2.x EntityBean with commit-option A and default locking where needed, and each time it is possible a NoLock policy. Instance per Transaction gives me a decrease in performance, and I was not able to use the new container configuration cmp2.x jdbc2 pm, I get a class cast exception in JBoss code at deploy time -- it is retrieving a collection of objects and try to cast all of them as jdbc2.* objects. I imagined it was impossible to mix the new and old configurations, so I tried to configure all my beans with the new pm and still got the class cast exception.
Thanks for any hint !
There's a MDB pool (how many MDB objects JBoss creates) and a MDB invocation pool, which is the number concurrent JMS sessions JBoss creates. Take a look at the singleton configuration and copy it.
Likely, you only have two MDB instances but JBoss is still creating 5-15 JMS sessions, all competing for them.