I see no evidence that the statement
The developer of an MDB wants to ensure that a message is redelivered if the onMessage method of the bean throws RuntimeException, then he should use CMT with transaction attribute REQUIRED.
is correct. Also the argument based on core spec 5.4.12 from Jun Liu doesn't seem to be really convincing to me. For, core spec 5.4.17 says
If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the container should not acknowlegde the message.
According to core spec 5.4.14 a JMS-MDB with BMT can use the acknowledge mode AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE and according to JMS 1.1 spec 4.5.2:
The result of a listener [that's the MDB in our context, remark by me] throwing a RuntimeException depends on the session's acknowledge mode.
AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE - the message will be immediately redelivered. The number of times a JMS provider will redeliver the same message before giving up is provider dependent.
In my words: If the onMessage method of a MDB with BMT throws a RuntimeException, then the container doesn't acknowlege the method. And because of a missing acknowlegement the JMS provider redelivers the message.
Therefore I see no need to use CMT in order to ensure message redelivery due to a RuntimeException.
The situation changes if one has the stronger requirement that message redelivery should be ensured if a transaction rollback occurs: Then one has to use CMT as explained by Jun Liu above.