The following servers are supported for multi-site update using MTS-coordinated transactions:
DB2 Universal Database Enterprise Edition Version 5.2
DB2 Extended Enterprise Edition Version 5.2
DB2 for OS/390
DB2 for MVS
DB2 for AS/400
DB2 for VM&VSE
DB2 Parallel Edition Version 1.2
DB2 common server Version 2
DB2 Universal Database for AIX with PTF U453782
DB2 Universal Database for HP-UX with PTF U453784
DB2 Universal Database Enterprise Edition for OS/2 with PTF WR09033
DB2 Universal Database for SOLARIS with PTF U453783
DB2 Universal Database Enterprise Edition for Windows NT with PTF WR09034
DB2 Universal Database Extended Enterprise Edition for UNIX or Windows NT.
MTS Transaction Time-Out and DB2 Connection Behavior
You can set the transaction time-out value in the MTS Explorer tool. Please refer to the online MTS Administrator Guide for more details.
If a transaction takes longer than the transaction time-out value (default is 60 seconds), MTS will asynchronously issue an abort to all Resource Managers involved, and the whole transaction is aborted.
For the connection to a DB2 server, the abort is translated into a DB2 rollback request. Like any other database requests, the rollback request will be serialized on the connection to guarantee the integrity of the data on the database server.
As a result:
If the connection is idle, the rollback is executed immediately.
If a long running SQL statement is being executed, the rollback request will wait until the SQL statement finished before it is executed.
Connection pooling enables an application to use a connection from a pool of connections, so that the connection does not need to be reestablished for each use. Once a connection has been created and placed in a pool, an application can reuse that connection without performing a complete connection process. The connection is pooled when the application disconnects from the ODBC data source, and will be given to a new connection whose attributes are the same.
Connection pooling has been a feature of ODBC driver Manager 2.x. With the latest ODBC driver manager (version 3.5) that was shipped with MTS, connection pooling has some configuration changes and new behavior for ODBC connections of transactional MTS COM objects (see “Reusing ODBC Connections Between COM Objects Participating in the Same Transaction”).
ODBC driver Manager 3.5 requires that the ODBC driver register a new keyword in the registry before it allows connection pooling to be activated. The keyword is:
Key Name: SOFTWARE\ODBC\ODBCINST.INI\IBM DB2 ODBC DRIVER
Name: CPTimeout
Type: REG_SZ
Data: 60
Because the IBM DB2 ODBC driver fully supports connection pooling, this keyword is now installed with Fix Pack 3 (WR09024) for Client Application Enabler for Windows NT or Client Application Enabler for Windows 95.
The default value (60) means the connection will be pooled for 60 seconds before it actually is disconnected. A value of 0 means the pooled connections will never time out.
In a busy environment, it is better to increase the CPTimeout value to a large number (Microsoft sometimes suggests 10 minutes for certain environments) to prevent too many physical connects and disconnects, because these consume a large amount of system resources, including system memory and communications stack resource.
Reusing ODBC Connections Between COM Objects Participating in the Same Transaction
ODBC connections in MTS COM objects have connection pooling turned on automatically (whether or not the COM object is transactional) .
For multiple MTS COM objects participating in the same transaction, the connection can be reused between two or more COM objects in the following manner.
Suppose there are two COM objects, COM1 and COM2 that connect to the same ODBC datasource and participate in the same transaction.
After COM1 connects and does its work, it disconnects and the connection is pooled. However, this connection will be reserved for the use of other COM objects of the same transaction. It will be available to other transactions only after the current transaction ends.
When COM2 is invoked in the same transaction, it is given the pooled connection. MTS will ensure that the connection can only be given to the COM objects that are participating in the same transaction.
On the other hand, if COM1 does not explicitly disconnect, then it will tie up the connection until the transaction ends. When
以下文章点击率最高
Loading…