Table of contents

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 10.5 Version 10.5, Fix Pack 1 or later Transaction-level and connection-level workload balancing

Automatic client reroute that is based on workload

Client affinities

Server features: Member Subsetting

Db2 Version 11.1 Version 10.5, Fix Pack 1 or later

Transaction-level and connection-level workload balancing

Automatic client reroute that is based on workload

Client affinities

Server features: Member Subsetting, Member Subset Failover Priority

Db2 Version 11.5 Version 10.5, Fix Pack 1 or later Transaction-level and connection-level workload balancing

Automatic client reroute that is based on workload

Client affinities

Server features: Member Subsetting, Member Subset Failover Priority

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.

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 timeout or a deadlock within global transactions. The lock timeout or deadlock occurs because data sharing members can share locks only if multiple branches within a global transaction connect to the same member. An application might not be able to use workload balancing but it can use client affinity for high availability.