It may be helpful if the spec defined what should happen if a JMS MDB receives a message and then rolls back the transaction, typically because setRollbackOnly has been called. If the rollback is caused by a system error (such as a database failure) then the same message might be redelivered and rolled back repeatedly.
Possible behaviour that might be required is:
- A delay before the message is redelivered - perhaps increasing as the number of redelivery attempts increases
- A maximum number of consecutive rollbacks after which the message will be delivered to a dead-message queue
No doubt there are other possibilities.
It would of course be necessary to allow this behaviour to be configured, perhaps using activation properties.