Resolving WebSphere® Application Server indoubt units of recovery

A global transaction is a unit of work that involves operations on multiple resource managers, such as Db2. All of the operations that comprise a global transaction are managed by a transaction manager, such as WebSphere Application Server.

About this task

When the transaction manager receives transactionally demarcated requests from an application, it translates the requests into a series of transaction control commands, which it directs to the participating resource managers.

For example, an application requests updates to multiple databases. The transaction manager translates these update requests into transaction control commands that are passed to several resource managers. Each resource manager then performs its own set of operations on a database. When the application issues a COMMIT, the transaction manager coordinates the commit of the distributed transaction across all participating resource managers by using the two-phase commit protocol. If any resource manager is unable to complete its portion of the global transaction, the transaction manager directs all participating resource managers to roll back the operations that they performed on behalf of the global transaction.

If a communication failure occurs between the first phase (prepare) and the second phase (commit decision) of a commit, an indoubt transaction is created on the resource manager that experienced the failure. When an indoubt transaction is created, a message like this is displayed on the console of the resource manager: 

DSNL405I  = THREAD
G91E1E35.GFA7.00F962CC4611.0001=217
PLACED IN INDOUBT STATE BECAUSE OF
COMMUNICATION FAILURE WITH COORDINATOR ::FFFF:9.30.30.53.
INFORMATION RECORDED IN TRACE RECORD WITH IFCID=209
AND IFCID SEQUENCE NUMBER=00000001

After a failure, WebSphere Application Server is responsible for resolving indoubt transactions and for handling any failure recovery. To perform these functions, the server must be restarted and the recovery process initiated by an operator. You can also manually resolve indoubt transactions with the RECOVER INDOUBT command.

Recommendation: Let WebSphere Application Server resolve the indoubt transactions. Manually recover indoubt transactions only as a last resort to start Db2 and to release locks.

Procedure

Begin general-use programming interface information.To manually resolve indoubt transactions:

  1. Issue the command -DISPLAY THREAD(*) T(I) DETAIL to display indoubt threads from the resource manager console.
    This command produces output like this example: 
        =dis thd(*) t(i) detail
    DSNV401I  = DISPLAY THREAD REPORT FOLLOWS - 
    DSNV406I  = INDOUBT THREADS - 
    COORDINATOR               STATUS      RESET URID         AUTHID
 1  ::FFFF:9.30.30.53..4007   INDOUBT     0000111F049A       ADMF002
     V437-WORKSTATION=jaijeetsvl, USERID=admf002, 
          APPLICATION NAME=db2jccmain
 2   V440-XID=7C7146CE 00000014 00000021 F6EF6F8B
             F36873BE A37AC6BC 256F295D 04BE7EE0
             8DFEF680 D1A6EFD5 8C0E6343 67679239
             CC15A350 65BFB8EA 670CEBF4 E85938E0
             06
 2   V467-HAS LUWID G91E1E35.GFA7.00F962CC4611.0001=217
     V466-THREAD HAS BEEN INDOUBT FOR    00:00:17
    DISPLAY INDOUBT REPORT COMPLETE
    Key
    Description
     1 
    Note that in this example, only one indoubt thread exists.
     2 
    A transaction is identified by a transaction identifier, called an XID. The first 4 bytes of the XID (in this case, 7C7146CE) identify the transaction manager. Each XID is associated with a logical unit of work ID (LUWID) at the Db2 server. Note the LUWID that is associated with each transaction, for use in the recovery step.
  2. Query the transaction manager to determine whether a commit or abort decision was made for each transaction.
  3. Based on the decision that is recorded by the transaction manager, recover each indoubt thread from the resource manager console by either committing or aborting the transaction. Specify the LUWID from the DISPLAY THREAD command in step 1. Use either of the following commands:
    • -RECOVER INDOUBT ACTION(COMMIT) LUWID(217)
    • -RECOVER INDOUBT ACTION(ABORT) LUWID(217)

    Either command produces output like this example: 

      =RECOVER INDOUBT ACTION(COMMIT) LUWID(217) 
  DSNV414I  = THREAD
  LUWID=G91E1E35.GFA7.00F962CC4611.0001=217 COMMIT 
  SCHEDULED 
  DSN9022I  = DSNVRI '-RECOVER INDOUBT' NORMAL COMPLETION
  4. Display indoubt threads again from the resource manager console by issuing the -DISPLAY THREAD(*) T(I) DETAIL command.

    This command produces output like this example: 

        =dis thd(*) t(i) detail
    DSNV401I  = DISPLAY THREAD REPORT FOLLOWS - 
    DSNV406I  = INDOUBT THREADS - 
    COORDINATOR               STATUS      RESET URID         AUTHID
 1  ::FFFF:9.30.30.53..4007   COMMITTED-H 0000111F049A       ADMF002
     V437-WORKSTATION=jaijeetsvl, USERID=admf002,
          APPLICATION NAME=db2jccmain 
     V440-XID=7C7146CE 00000014 00000021 F6EF6F8B 
              F36873BE A37AC6BC 256F295D 04BE7EE0 
              8DFEF680 D1A6EFD5 8C0E6343 67679239 
              CC15A350 65BFB8EA 670CEBF4 E85938E0 
              06 
     V467-HAS LUWID G91E1E35.GFA7.00F962CC4611.0001=217 
    - DISPLAY INDOUBT REPORT COMPLETE
    Key
    Description
     1 
    Notice that the transaction now appears as a heuristically committed transaction (COMMITTED=H).
  5. If the transaction manager does not recover the indoubt transactions in a timely manner, reset the transactions from the resource manager console to purge the indoubt thread information. Specify the IP address and port from the DISPLAY THREAD command in step 1 by issuing the -RESET INDOUBT IPADDR(::FFFF:9.30.30.53..4007)FORCE command.

    This command produces output like this example: 

     =RESET INDOUBT IPADDR(::FFFF:9.30.30.53..4007)FORCE 
 DSNL455I  = DB2 HAS NO INFORMATION RELATED TO 
 IPADDR 9.30.30.53:4007 
 DSNL454I  = QUALIFYING INDOUBT INFORMATION FOR 
 IPADDR 9.30.30.53:4007 HAS BEEN PURGED
    End general-use programming interface information.