Db2 Database transaction manager configuration

There are a number of ways that you can set up transaction management. You can use a third-party transaction manager, or you can use the transaction manager that comes with Db2.

If you are using an XA-compliant transaction manager, such as IBM® WebSphere®, BEA Tuxedo, or Microsoft Transaction Server, you should follow the configuration instructions for that product.

When using Db2 to coordinate your transactions, you must fulfill certain configuration requirements. Configuration is straightforward if you use TCP/IP exclusively for communications and Db2 or Db2 for i5/OS, Db2 for z/OS® are the only database servers involved in your transactions.

Db2 and Db2 for z/OS, and i5/OS using TCP/IP Connectivity

If each of the following statements is true for your environment, the configuration steps for multisite update are straightforward.

  • All communications with remote database servers (including Db2 for z/OS and i5/OS) use TCP/IP exclusively.
  • Db2 or Db2 for z/OS, OS/390® or i5/OS are the only database servers involved in the transaction.

The database that will be used as the transaction manager database is determined at the database client by the database manager configuration parameter tm_database. Consider the following factors when setting this configuration parameter:

  • The transaction manager database can be:
    • A Db2 Version 9 or later database
    • A Db2 for z/OS Version 7 or later database
    • A Db2 for IBM i Version 5 or later database
  • If a value of 1ST_CONN is specified for the tm_database configuration parameter, the first database to which an application connects is used as the transaction manager database.
  • If using TCP/IP version 6. The IP address is created depending on the operating system configuration mode chosen.
  • If using Auto Configuration mode. The MAC address is extracted from the IPv6 address and is used within the internal Db2 Coordinator's Unit of Work Identifier. No configuration changes are required.
  • If using Manual Configuration mode. The internal Db2 Coordinator's Unit of Work Identifier is created using the last 6 bytes of the IPv6 address. To prevent collision, the user must ensure that the last 6 bytes of the IPv6 addresses within the network are unique.
Note:
  1. Db2 Coordinator is the Db2 client and configuration changes must be performed on the system where the Db2 client exists.
  2. If your application attempts to disconnect from the database being used as the transaction manager database, you will receive a warning message, and the connection will be held until the unit of work is committed.

Configuration parameters for transaction managers

You should consider the following configuration parameters when you are setting up your environment to support transaction managers.

Database Manager Configuration Parameters

  • tm_database

    This parameter identifies the name of the Transaction Manager (TM) database for each Db2 instance.

  • spm_name

    This parameter identifies the name of the Db2 Connect sync point manager instance to the database manager. For resynchronization to be successful, the name must be unique across your network.

  • resync_interval

    This parameter identifies the time interval (in seconds) after which the Db2 Transaction Manager, the Db2 server database manager, and the Db2 Connect sync point manager or the Db2 sync point manager should retry the recovery of any outstanding indoubt transactions.

  • spm_log_file_sz

    This parameter specifies the size (in 4 KB pages) of the SPM log file.

  • spm_max_resync

    This parameter identifies the number of agents that can simultaneously perform resynchronization operations.

  • spm_log_path

    This parameter identifies the log path for the SPM log files.

Database Configuration Parameters

  • maxappls

    This parameter specifies the maximum permitted number of active applications. Its value must be equal to or greater than the sum of the connected applications, plus the number of these applications that may be concurrently in the process of completing a two-phase commit or rollback, plus the anticipated number of indoubt transactions that might exist at any one time.

  • autorestart

    This database configuration parameter specifies whether the RESTART DATABASE routine will be invoked automatically when needed. The default value is YES (that is, enabled).

    A database containing indoubt transactions requires a restart database operation to start up. If autorestart is not enabled when the last connection to the database is dropped, the next connection will fail and require an explicit RESTART DATABASE invocation. This condition will exist until the indoubt transactions have been removed, either by the transaction manager's resynchronization operation, or through a heuristic operation initiated by the administrator. When the RESTART DATABASE command is issued, a message is returned if there are any indoubt transactions in the database. The administrator can then use the LIST INDOUBT TRANSACTIONS command and other Command Line Processor (CLP) commands to get information about those indoubt transactions.