One other thing to note is that our redelivery behaviour differs from our competitors:
The actual reason redelivery doesn't occur is that the MDB container which sits between the JMS provider and the customer provide onMessage implementation, catches the RuntimeException and wraps it in an EJBException.
So when it gets to the JMS provider it's no longer a RuntimeException and the JMS provider won't redeliver the message (JMS says any RuntimeExceptions should cause redelivery).
Technically, there is nothing to *force* us to redeliver the message in the case of a non specified transaction context (ie BMT, CMT NotSupported). All specs are at best ambiguous, and at worst, completely ingnorant of this subject. However, a customer requirement (not supported by me mind you) came up and this *feature* was added to the JCA adapter. This change initially was added in HEAD and then aggressively, and stupidly might I add, backported to multiple branches on the 4.x line.
After the dust cleared I went back in HEAD and reworked some of it to be more performant and easier to understand. I haven't backported these changes yet.
So, the long and short of it:
If you want redelivery in the case of BMT, CMT NotSupported you
a) Have to use JCA
b) Are encouraged, if at all possible, to use the current implementation in HEAD.