I've just found some EJB behaviour which looks rather surprizing to me.
Here is the code sample (for sure MyBean, beanA, beanB are EJBs using CMT):
@Stateless
public class MyBean {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void myMethod(){
try {
beanA.methodA(); /* annotated as REQUIRED */
} catch (Exception e) {
beanB.methodB(); /* annotated as NOT_SUPPORTED */
}
}
}
Lets's say methodA takes more than transaction timeout to execute, so once it returns myMethod receives TransactionRolledbackException, which is successfully caught then in "myMethod".
I would expect "methodB" be called so far, as accordingly with EJB spec it must be called without any transaction context. But actually, the "beanB" proxy simply returns another TransactionRolledbackException, the "methodB" is not executed.
Looking through EJB spec I do not see anything to prove that container should or even might behave that way.
Do I miss something? Any hint would be appreciated.
UPDATE
At least for Websphere, this behaviour appears to be timeout-specific. The "rollbackOnly" flag which for example is set when "methodA" throws a RuntimeException, does not prevent "methodB" from execution. Only timeout flag does.