So far I havn't found any elegent solution, however, I have a workaround, though it will introduces non-business code into your MDB.
1) Inject EJBContext to your MDB
2) Use ejbContext.getRollbackOnly() method to check whether the current transaction already rollback before continue process. If current transaction has been canceled, skip the following process till the end.
This solution should be safe in only database operating situation, meanwhile there still has a drawback for this solution. Please look at the following situation.
1) The some operations to a share resource which is not rollbackable, such as writing strings to a file in this transaction.
2) Redelivery Delay is 0 and Max Delivery Attempts more than 1
Once the transaction timeout, JMS will redeliver the message, but the previous message still on processing which is writing strings to a file. At this time, the file is operating by 2 threads and this may cause error. So it should be considered how to handle the resource conflict in this case.
Am I missing sth? please comment.