It is virtually impossible for a JMS to guarantee this behaviour and still be efficient. The problem comes because a rollback/retry maybe initiated at some later date by the transaction manager for in-doubt transactions. The in-doubt transaction could be in an unfinished state because another branch of the XA transaction (e.g. database updates) may not be able to proceed through the commit stage (e.g. the database has crashed and needs recovering). This is not an issue unique to JBoss, e.g. http://www.devwebsphere.com/devwebsphere/2005/06/total_jms_messa.html which also identifies some of the other pitfalls which presumably you're less likely to make since they are more under your control. ;-) Having said that, it can be done and there a feature request for it: https://jira.jboss.org/jira/browse/JBMESSAGING-1151 so you can vote for it. The main issue with this solution (don't deliver any other message to clients until you get an ACK from the one message that is allowed to be delivered) is that any in doubt XA transaction would have to be resolved in order to resume message delivery and there is increased latency for normal message delivery. If you want to implement it yourself then the MDB has to be aware of the order and NACK/rollback message deliveries that appear out of order. Again not very efficient, and not that easy to do across redeploys of the MDB without persisting the lastest order number somewhere. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179615#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...