Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate Messaging resources > Migrate from WAS v5 embedded messaging > Migrate v5.1 messages using the message migration utility


XA recovery

When a message is migrated between WAS v5 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. For XA recovery to complete successfully:

  1. All the resources involved in the transaction must be available to the transaction manager.

    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, v5 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.

    When a transaction is in an indoubt state, information about the resources is saved in the transaction log.

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 v5 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: 

WAS_HOME/profiles/Profile1/logs/message_migration_utility.log
where WAS_HOME is the root directory for the installation of WAS.

The log file contains details of every run of the utility. If we 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 WAS v5
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 WAS vversion_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
: v5.1 -> vversion_number
   version_number reliability    : ReliablePersistent


Procedure

  1. Start the v5 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.

+

Search Tips   |   Advanced Search