All transactions initiated by client applications are tracked by the broker. These can be simple Message Queue transactions or distributed transactions managed by a distributed transaction (XA resource) manager.
Each transaction is identified by a unique 64-bit Message Queue transaction identifier. Distributed transactions also have a distributed transaction identifier (XID), up to 128 bytes long, assigned by the distributed transaction manager. Message Queue maintains the association between its own transaction identifiers and the corresponding XIDs.
imqcmd list txn
This lists all transactions on the broker, both local and distributed. For each transaction, it shows the transaction ID, state, user name, number of messages and acknowledgments, and creation time. Example 5–9 shows an example of the resulting output.
imqcmd query txn -n transactionID
This displays the same information as imqcmd list txn, along with the client identifier, connection identification, and distributed transaction identifier (XID). For example, the command
imqcmd query txn -n 64248349708800
produces output like that shown in Example 5–10.
In case of broker failure, it is possible that a distributed transaction could be left in the prepared state without ever being committed. Until such a transaction is committed, its messages will not be delivered and its acknowledgments will not be processed. Hence, as an administrator, you may need to monitor such transactions and commit them or roll them back manually. For example, if the broker’s imq.transaction.autorollback property (see Table 14–2) is set to false, you must manually commit or roll back transactions found in the prepared state at broker startup, using the Command utility’s commit txn or rollback txn subcommand:
imqcmd commit txn -n transactionID
imqcmd rollback txn -n transactionID
For example, the following command commits the transaction listed in Example 5–10:
imqcmd commit txn -n64248349708800
Only transactions in the prepared state can be committed or rolled back. You should do so only if you know that the transaction has been left in this state by a failure and is not in the process of being committed by the distributed transaction manager.