Tracing distributed unit of work transaction states across data sources

If you decide to resolve indoubt transactions manually instead of letting synchronization resolve them automatically, tracing transactions in the federated system is essential. When you are tracing an indoubt distributed unit of work transaction, the only way to determine the data source or data sources that failed is to capture the XID for the failed transaction.

You must look for that XID in the data source database managers for all of the data sources that a federated server might have accessed as a part of the distributed unit of work transaction.

To determine the identifier and state of each transaction that is involved in the distributed unit of work that you want to trace, issue the LIST INDOUBT TRANSACTIONS command in your application database, the federated database, and any data sources in the distributed unit of work transaction.

Note: Each data source that supports the two-phase commit protocol might use a different command. Search for the string XID in the command documentation for your specific data source.

The federated transaction manager generates an XID in hexadecimal format during transaction processing. This XID begins with the format identifier of F2PC, which is the number 46325243 in hexadecimal format. The federated transaction manager sends the XID to the data sources. Before a federated server sends an XID to a data source, however, the federated server changes the XID so that it conforms to the XID format of that data source. These modifications include updating the branch qualifier length section of the XID and adding the branch qualifier section of the XID.

You might need to compare XIDs across several data sources, so you must know which part of the XID that you can accurately compare across your environment when you trace an XID.

For example, the transaction manager is a Db2® database. When you issue the LIST INDOUBT TRANSACTIONS command at the database, a string in hexadecimal representation is returned for the transaction XID that is similar to the following one:

463250430000019 000000004739314533463135 2E47453934000000 000000000000E80000

This string is actually composed of several distinct parts:

Format ID	Transaction identifier length	Branch qualifier length	Transaction identifier
46325043	00000019	00000000	4739314533463135 2E47453934000000 000000000000E800 00

The values listed in the string are hexadecimal. For example, the transaction identifier length (hexadecimal 19) represents the decimal value 25.

If that same XID is passed from a federated server that acts as a federated transaction manager to a data source that acts as a resource manager, the XID string is appended. For example, the XID that is passed to a resource manager for a Db2 database system for Windows data source changes to the following format:

463252430000019 000000014739314533463135 2E47453934000000  000000000000E8000001

Here is that same changed XID string broken down into the standard parts:

Format ID	TID length	Branch qualifier length	Transaction identifier	Branch qualifier
46325043	00000019	00000001	4739314533463135 2E47453934000000 000000000000E800 00	01

The branch qualifier length now has a 1, and the branch qualifier section is added. However, the transaction identifier field has not changed. You can still trace the XID across different data sources by limiting your search string input to the transaction identifier section.