Ordering Group -- Transaction Scenario Analysis Abbrev Used: M1, M2, etc - Messages of the order of 1, 2, etc. that belong to an ordering group. R - The message receiver. TM - Transaction Manager XATx - A XA Transaction XAResJms - A XAResource from a JMS session. XAResDB - A XAResource from a DB connection. xid - Transaction ID of XATx. 1) M1 arrives at R, R's onMessage(M1) is called. 2) A XATx is started by the TM for the purpose of onMessage call. 3) The onMessage() method accepts the M1 and does some updates on the target DB accordingly (within the XATx context). 4) After onMessage() ends, TM starts to end the XATx. 5) It first gets the XAResJms and XAResDB and issues prepare(xid) on them respectively. M1 at this point is still not completed and M2 is blocked. 6) If prepare calls result in roll back, On XAResJms.rollback(), M1 will be released from the ordering group and M2 will subsequently available for delivery. 7) If all prepare's replies are positive, TM goes on with commit. 8) The commit() on XAResJms causes the M1 to be acknowledged and thus make M2's delivery possible. In this case, even the success of this commit doesn't mean that M1 is completed regarding ordering group rule, Simply because there may be other XA resources (XAResDB in this case) whose commit() may fail. JMS must not permit the deliver of M2 at this point of time and must be always aware of any recovery in the future. This means JMS server should not forget the M1 at this point. 9) The commit() on XAResDB causes the updates to really happen. 10) XAException from either of the above commits will fail the XATx and TM will initiates a recovery on behalf of this XATx. Eventually the commit() or rollback() will be issued again on problematic resources during recovery. Only when XATx completed in any way, M1 is finished and M2 becomes available. We need a way to monitor XATx, see my thought below. ----Summary----- We've analysed the Transaction Scenario above regarding the ordering group issue. We focus on the transactions on message receiving end because it is where the user mostly concerns. To guarantee ordering group in such scenario, we need to enhance the JMS server so that *) On XAResJms.rollback(), M1 will be released from the ordering group and M2 will subsequently available for delivery. *) On XAResJms.commit(), remember (in-mem and/or persist) the M1. We hold the M1 until we found the Transaction is completed. This can be achieved by obtaining the javax.transaction.Transaction object and keep calling Transaction.getStatus() (thread may be used). Until the status is STATUS_COMMITTED or STATUS_ROLLEDBACK, we release M1, otherwise we hold M1 and block M2. (but if server dies when keep querying status, we will lose the Transaction, how do we get it back after server is up? any API available?) If there is no way to do this, or not worth it, we just forget M1 simply after commit(). *) Local transactions should be handled the similar way as if it is a one_phase commit XA transaction. *) Multiple Ordering Messages in transaction is impossible because ordering group only release one message at a time but the transaction requires all or none at a time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183465#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...