DB2 10.5 for Linux, UNIX, and Windows

DB2 client support for the DB2 pureScale Feature

For your application to make full use of the DB2® pureScale® Feature, your clients and servers must be at certain release levels.

The following table shows the supported release levels for clients and servers:

Server version	Client version	Features available
DB2 Version 9.8, or later	Version 9.7, Fix Pack 1, or later	Transaction-level and connection-level workload balancing Automatic client reroute that is based on workload Client affinities
DB2 Version 9.8, or later	Version 9.1, Version 9.5, and Version 9.7 (before Fix Pack 1)	Connection-level workload balancing (transaction-level workload balancing is unavailable) Automatic client reroute that is based on workload
DB2 Version 10.1	Version 9.5, and Version 9.7 (before Fix Pack 1)	Connection-level workload balancing (transaction-level workload balancing is unavailable) Automatic client reroute based on workload
DB2 Version 10.1	Version 9.7, Fix Pack 1, or later	Transaction-level and connection-level workload balancing Automatic client reroute that is based on workload Client affinities
DB2 Version 10.5	Version 9.7, Fix Pack 1, or later	Transaction-level and connection-level workload balancing Automatic client reroute that is based on workload Client affinities

Client features

Automatic client reroute: Automatic client reroute (ACR) is a DB2 server feature that redirects client applications from a failed server to another server so the applications can continue their work with minimal interruption. The connection failover for the automatic client reroute feature can be seamless or non-seamless.
Client affinities: Client affinities provide an ordered list of members to which the client can connect. There is no consideration for the workload of the members, if the first member is unavailable, or if your client is connected to it and it becomes unavailable, the automatic client reroute feature attempts to connect to the next member in the list.
Workload balancing: Automatic workload balancing (WLB) uses member workload information contained in the server list as returned by a DB2 pureScale database server to enable the client to distribute work in a balanced fashion among members.

For further information about using these client features, search the DB2 Information Center for information about client high availability connections to DB2 database servers.

Restrictions for workload balancing and automatic client reroute

During COMMIT and ROLLBACK operations, DB2 pureScale database servers prevent applications from using workload balancing if any of the following conditions apply:

The connection uses global variables.
An encrypted password is used.
Open WITH HOLD cursors are used.
Declared temporary tables (DGTT) are used.
A transform group was set.
The session authorization ID was changed.
PL/SQL packages or SQL/PL modules are used.
Cursor variables are used.
Sequence values are used and DB2_ALLOW_WLB_WITH_SEQUENCES communication variable is not enabled.
Created temporary tables (CGTTs) that were created with the PRESERVE ROWS option are used.

For applications that use CLI, ODBC, .NET, or JDBC APIs, if workload balancing is not allowed as a result of any of the preceding conditions, then automatic client reroute is non-seamless and affinity failback is disabled.

For applications that do not use CLI, ODBC, .NET, or JDBC APIs, such as applications that use embedded SQL, in addition to the conditions listed, the use of dynamic SQL must also be considered when it comes to workload balancing. By default, workload balancing is disabled for such applications after a statement is prepared unless the statement is prepared in a stored procedure or user-defined function. However, if the statement is always reprepared in a new transaction before it is executed, you can allow workload balancing by specifying either the KEEPDYNAMIC NO option for the bind operation or the KEEP DYNAMIC NO option for the ALTER PACKAGE statement. For applications that do not use CLI, ODBC, .NET, or JDBC APIs, automatic client reroute is always non-seamless and affinity failback is disabled under the conditions that restrict workload balancing.

For applications that use CLI, ODBC, .NET, or JDBC APIs, the use of dynamic SQL has no bearing on whether workload balancing is allowed or whether automatic client reroute is seamless or non-seamless.

Restriction for loosely coupled XA transactions with workload balancing

In loosely coupled XA transactions, if there are multiple branches open against the same resource manager an application can encounter lock-time or a deadlock within global transactions. The lock-time or deadlock occurs because data sharing members can share locks only if multiple branches within a global transaction land on the same member. An application might not be able to use workload balancing but it can use client affinity for high availability.