EJB 3.x onMessage() vs @Timeout transactional context

in EJB 3.x for both the onMessage() method of MDBs and the @Timeout method of SLSBs and MDBs there is no transaction propagation. That is, there is no client for the execution of the method, so a transaction can'开发者_如何学编程t be possibly propagated.

When using Container-managed transactions, I would expect the two cases to accept the same javax.ejb.TransactionAttributeType. However, they don't.

For the onMessage() method, REQUIRED and NOT_SUPPORTED are the acceptable transaction attributes, whereas for @Timeout methods REQUIRED, REQUIRES_NEW and NOT_SUPPORTED.

In particular, for the @Timeout methods the spec says (par. 18.2.8):

Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This transaction attribute value is allowed so that specification of a transaction attribute for the timeout callback method can be defaulted.

If I get this correctly, normally REQUIRES_NEW should be used here, but because REQUIRED is the default for an EJB, it is also allowed for @Timeout methods, giving it the same semantic as REQUIRES_NEW, since there is no possibility of a transaction to be propagated.

Questions:

1. Is my understanding correct?
2. Why isn't REQUIRES_NEW acceptable also in onMessage()? Is it different somehow in respect of transactions?

UPDATE: The same goes for other cases where REQUIRES_NEW is supported: @Asynchronous and @PostConstruct/@PreDestroy methods.

1. Yes, your understanding is correct.

2. In my opinion, @Timeout is odd for specifying REQUIRES_NEW. The spec basically requires that the container update the persistent timer database within the same transaction as the timeout method. This isn't really any different than transactional JCA message delivery, except that it's more apparent in the JCA scenario that an external component is handling the transaction. I suppose you could argue that there is no JavaEE component driving the @Timeout method, but in my opinion, it would have been better to disallow REQUIRES_NEW for both. Regardless, the inconsistency is odd, so perhaps MDB will be updated in a later version of the spec to allow REQUIRES_NEW.