When a (transactional) method of an EJB calls another (transactional) method of another EJB, and an exception is thrown in the second, but catched in the first one, it seems tha
Transaction is rolled back in case you throw a RuntimeException
or any Exception which have @ApplicationException
annotation with rollback
attribute set to true
, so:
@ApplicationException(rollback=true)
public class MyException extends Exception {
// ...
}
will rollback the current transaction.
By default ApplicationException doesn't rollback your transaction.
If you don't want to methodB to rollback your transaction you can either change the rollback behavior of your ApplicationException
or prevent the transaction sharing.
The latter is achievable by changing the TransactionAttribute
of methodB i.e. to RequiresNew
. Then methodA transaction (Tx1) will be suspendend and in case methodB throws an exception which results in rollback of its transaction (Tx2), you can still catch it in methodA and prevent rollback of your methodA transaction (Tx1).
Yes, it's true, if the exception is a runtime exception. Checked exceptions don't cause a transaction rollback.
To avoid it, just make sure that the code in methodB
doesn't throw any runtime exception. A runtime exception normally indicates a bug, or a state which doesn't allow for continuing the work.