EJB called from another, specifically Message driven bean with container transaction.

The other day I had a weird defect in the application I worked on, we had a Message driven bean [MDB] calling another EJB inside the message processing code and everything was working fine and passed two different testing periods.

after going live on production something happened, the MDB received a message and invoked the EJB to do some work, that work included calling a web service, this service client thrown time out exception and thrown an exception and the EJB couldn't finish its work because that's what is expected, the weird thing is that the exact same message was reprocessed by the MDB automatically.. we don't have anything in our code that did that.

this didn't happen before with other EJBs called from an MDB..

after thorough investigation I found the following :

1- The MDB uses container transaction [ found configuration in the ejb-jar.xml] (this is used in EJB2)
2-  The EJB method that was invoked also had container transaction configured with transaction attribute as Required
3- When an exception is thrown from the EJB method, it calls : context.setRollBackOnly(); which means the container transaction will roll back

but why was the message reprocessed again? Luckily in production the service didn't time out the second time and the message was processed successfully, but I did a test where the EJB always fails and that led in having the MDB reprocessing the message indefinitely until I shutdown the server.

I tried and changed the EJB transaction attribute in the ejb-jar.xml to 'RequiresNew' instead of 'Required' because at that point I felt that there is a relation between the transaction failing in the EJB and the MDB transaction [Yes MDBs have transactions] and that WORKED.

it's critical to configure the EJBs [ MDB is an EJB ] transactions to match the need of the application, in our case we didn't want the message to be reprocessed everytime it failed, so a new transaction in the EJB did the trick