XA recovery

When a message is migrated between WebSphere® Application Server Version 5 embedded messaging and the service integration bus on a later version of the product, an XA transaction is used. This ensures that the movement of a single message is carried out as a single unit of work even though there are two discrete and separate resources involved. If a transaction is in an indoubt state, the transaction manager attempts to recover the transaction when the application server next restarts.

Before you begin

For XA recovery to complete successfully:
  1. All the resources involved in the transaction must be available to the transaction manager.
    Note: This is not a problem for the default messaging provider (the service integration bus) in later versions of the product, because it starts when the server (and the transaction manager) start. However, Version 5 embedded messaging is not told that the server is starting, and the embedded queue manager needs to be started manually to allow XA recovery to complete.
  2. The resources involved must be started in the same way. The queue manager must be started using the same startup parameters, for example, the same TCP/IP port number as before.
    Note: When a transaction is in an indoubt state, information about the resources is saved in the transaction log.

About this task

The XA transaction uses two-phase commit, which ensures that all resources participating in a transaction are asked to "prepare" to commit and then, when all the resources have indicated they are ready, the transaction commits. XA transactions are coordinated by a transaction manager, which informs the resources to prepare, commit or roll back.

There is one XA transaction for each migrating message, and the controlling transaction manager is part of the service integration bus, although you will probably be unaware that the transaction manager is involved.

It is possible for a transaction to be in an indoubt state. This can occur if the transaction manager has told the participants in a transaction to prepare and they have successfully done so, but an error has occurred when the final commit is attempted. This can be caused by a communications failure between the transaction manager and a transaction participant. The recovery process generally involves reconnecting to each of the participants and telling them to roll back the transaction.

When the message migration utility connects to the Version 5 embedded messaging server, it creates a log of the connection parameters that were used in your profile directory on the server at the later level. For example, if the profile in use is "Profile1", then the log file is located in the following directory:

app_server_root/profiles/Profile1/logs/message_migration_utility.log
where app_server_root is the root directory for the installation of WebSphere Application Server.
Note: The log file contains details of every run of the utility. If you have run the utility more than once make sure that you go to the last entry.

Sample contents of the log file:

----------------------------------------------------------------
Migration Utility was started: Tue Feb 22 14:20:49 GMT 2005
----------------------------------------------------------------
   Browser details   : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) 
												Gecko/20041107 Firefox/1.0
   Referrer          : null
   Query String      : null
   User              : your.server.name:9080
 
Connection to WebSphere Application Server Version 5 
Embedded Messaging server was successful using the following properties:
 
   Queue Manager Name: WAS_Node01_server1
   Hostname          : your.server.name
   TCP/IP Port       : 21179
   SVRCONN Channel   : WAS.JMS.SVRCONN
 
Connection to WebSphere Application Server Version version_number 
default messaging provider was successful using the following properties:
 
   SIBus Name        : bus1
 
Message migration will take place using the following settings:
 
   Queues            : [queue2, queue1]
   Direction         : Version 5.1 -> Version version_number
   version_number reliability    : ReliablePersistent

Procedure

  1. Start the Version 5 embedded messaging queue manager.
    Use the following commands:
    1. strmqm queue_manager_name
    2. strmqcsv queue_manager_name
    3. runmqlsr -m queue_manager_name -t TCP -p TCP/IP_port
  2. Start the application server on the later version of the product, if it is not already started.

Results

XA recovery continues automatically.
Task topic Task topic    

Terms of Use | Feedback

Last updatedLast updated: Sep 19, 2011 6:15:55 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-express-dist&topic=tjnmmuxa
File name: tjnmmuxa.html