JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Administration Guide
search filter icon
search icon

Document Information


Part I Introduction to Message Queue Administration

1.  Administrative Tasks and Tools

2.  Quick-Start Tutorial

Part II Administrative Tasks

3.  Starting Brokers and Clients

4.  Configuring a Broker

5.  Managing a Broker

6.  Configuring and Managing Connection Services

7.  Managing Message Delivery

Configuring and Managing Physical Destinations

Command Utility Subcommands for Physical Destination Management

Creating and Destroying Physical Destinations

Naming Destinations

Setting Property Values

Destroying Destinations

Pausing and Resuming a Physical Destination

Purging a Physical Destination

Updating Physical Destination Properties

Viewing Physical Destination Information

Managing Physical Destination Disk Utilization

Using the Dead Message Queue

Managing the Dead Message Queue

Enabling Dead Message Logging

Managing Broker System-Wide Memory

Managing Durable Subscriptions

Managing Transactions

8.  Configuring Persistence Services

9.  Configuring and Managing Security Services

10.  Configuring and Managing Broker Clusters

11.  Managing Administered Objects

12.  Configuring and Managing Bridge Services

13.  Monitoring Broker Operations

14.  Analyzing and Tuning a Message Service

15.  Troubleshooting

Part III Reference

16.  Command Line Reference

17.  Broker Properties Reference

18.  Physical Destination Property Reference

19.  Administered Object Attribute Reference

20.  JMS Resource Adapter Property Reference

21.  Metrics Information Reference

22.  JES Monitoring Framework Reference

Part IV Appendixes

A.  Distribution-Specific Locations of Message Queue Data

B.  Stability of Message Queue Interfaces

C.  HTTP/HTTPS Support

D.  JMX Support

E.  Frequently Used Command Utility Commands


Managing Transactions

All transactions initiated by client applications are tracked by the broker. These can be local Message Queue transactions or distributed transactions managed by a distributed transaction 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.

The imqcmd list txn subcommand lists the transactions being tracked by a broker:

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 7-7 shows an example of the resulting output.

Example 7-7 Broker Transactions Listing

Transaction ID  State    User name   # Msgs/   Creation time
                                     # Acks

64248349708800  PREPARED  guest      4/0      1/30/02 10:08:31 AM
64248371287808  PREPARED  guest      0/4      1/30/02 10:09:55 AM

To display detailed information about a single transaction, obtain the transaction identifier from imqcmd list txn and pass it to the imqcmd query txn subcommand:

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 7-8.

Example 7-8 Transaction Information Listing

Client ID
Connection                 guest@>jms:62195
Creation time              1/30/02 10:08:31 AM
Number of acknowledgments  0
Number of messages         4
State                      PREPARED
Transaction ID             64248349708800
User name                  guest
XID                        6469706F6C7369646577696E6465723130313234313431313030373230

If a broker fails, it is possible that a distributed transaction could be left in the PREPARED state without ever having been 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 might 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 17-2) is set to false, you must manually commit or roll back non-distributed transactions and unrecoverable distributed 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 7-8:

imqcmd commit txn -n64248349708800

Note - Only transactions in the PREPARED state can be committed . However, transaction in the STARTED, FAILED, INCOMPLETE, COMPLETE, and PREPARED states can be 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.