XA in high-availability clusters

The X/Open Distributed Transaction Processing (DTP) Model allows an updatable secondary server in a high-availability cluster to serve as a resource manager in a distributed transaction.

There are three types of participants in any XA global transaction:
  • Application Program (AP): Defines transaction boundaries and specifies actions that constitute the transaction branch.
  • Resource Manager (RM): Provides access to the resources, such as databases.
  • Transaction Manager (TM): Assigns identifier (XID) to transaction branches, monitors transaction progress, coordinates the transaction branches into completion and failure recovery.

In a high-availability cluster, sessions are able to create or attach to a transaction branch from any server in the cluster. For example, a transaction branch detached from server_1 can be attached from server_2. The application can connect to the cluster using the Connection Manager without tracking the server on which the transaction began. The transaction manager can also connect to the cluster using the Connection Manager to complete an XA transaction by committing the transaction, rolling it back, or forgetting it, for both loosely and tightly coupled transactions (see Loosely-coupled and tightly-coupled modes).

All global transaction branches started from a secondary server are redirected to the primary server using the existing proxy interface. The primary server starts and maintains all transaction branches and performs all requested work associated with the branches.

When an XA transaction is started on an updatable secondary server, a corresponding XA transaction is started on the primary server. The XA transaction on the primary server executes the full life cycle of an XA transaction (start, end, prepare, and commit or roll back). XA transactions on secondary servers are used to support queries that are not redirected to the primary server. When a call to the xa_end() function is issued, the XA transaction is freed and the user session is detached from the XA transaction. All XA transaction requests and all write operations issued within the XA transaction are redirected to the primary server.

The following features are specific to the HCL OneDB™ XA implementation:
  • All XA interface requests are available on updatable secondary servers (see Database updates on secondary servers).
  • Starting, preparing, and committing or rolling back XA transactions from an updatable secondary server is supported.
  • The xa_recover() function, which obtains a list of prepared transaction branches from a resource manager, is supported.
  • XA transaction branch migration among high-availability cluster servers is supported. Any server in a cluster can attach to an XA transaction branch irrespective of whether the transaction branch was originated from it.
  • XA clients and the Transaction Manager can connect to any high-availability cluster server using the Connection Manager (see Connection management through the Connection Manager).
  • Redirection of XA requests from secondary servers to the primary server is supported.
  • Transaction survival is supported for XA transactions, with the exception of transaction completion after failover (see Transaction completion during cluster failover).
  • If a secondary server on which a redirected XA transaction is running fails, the transaction is rolled back.
  • Support is provided for SQL transactions that run within the XA environment but which are outside the XA transaction
The following restrictions exist for XA transactions running on secondary servers:
  • Resuming a suspended global transaction branch from a different user session (on the same or different secondary server) is not supported.
  • A user session cannot attach to a global transaction branch that is associated with a different user session on another secondary server.
  • XA transactions have the same restrictions as other data on secondary servers. See Database updates on secondary servers.
  • XA transactions cannot be started on read-only secondary servers. If an application attempts to create a new XA transaction on a read-only secondary server, it receives XA error code XAER_RMERR. In addition, running xa_prepare(), xa_commit(), or xa_rollback() on a read-only secondary server returns error code XA_NOTA (-4).
  • The following XA APIs are supported on read-only secondary servers:
    • xa_open()
    • xa_close()
Important: If you are using the .NET Framework with the Microsoft™ Transaction Server to manage XA transactions on a high availability cluster, you must use the TransactionScope class instead of the ServiceConfig class. The TransactionScope class is available in .NET Framework 3.5.