DB2 Database transaction manager

configuration
There are a number of ways that you can set up transaction management. You can use a thirdparty transaction manager, or you can use the transaction manager that comes with DB2 for
Linux, UNIX, and Windows.
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 for Linux, UNIX, and Windows to coordinate your transactions, you must
fulfill certain configuration requirements. Configuration is straightforward if you use TCP/IP
exclusively for communications and DB2 for Linux, UNIX, and Windows or DB2 for i5/OS,
z/OS or OS/390 are the only database servers involved in your transactions.

DB2 for Linux, UNIX, and Windows and DB2 for z/OS,
OS/390, 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, OS/390, and
i5/OS) use TCP/IP exclusively.

DB2 for Linux, UNIX, and Windows 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:

o A DB2 Universal Database for Linux, UNIX or Windows Version 8 or later
database
o A DB2 for Linux, UNIX and Windows Version 9 or later database
o A DB2 for z/OS and OS/390 Version 7 or later database
o A DB2 for i5/OS 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.