Operation of sysplex workload balancing for connections from Java clients to Db2 for z/OS servers

Sysplex workload balancing (also called transaction-level workload balancing) for connections to Db2 for z/OS contributes to high availability by balancing work among members of a data sharing group at the start of a transaction.

The following overview describes the steps that occur when a client connects to a Db2 for z/OS sysplex, and sysplex workload balancing is enabled:

1. When the application first establishes a connection using the sysplex-wide IP address, which is called the group IP address, or when a connection is reused by another connection object, the server returns a server list that contains member workload distribution information to the IBM® Data Server Driver for JDBC and SQLJ.

   The default lifespan of the cached server list is 30 seconds.

2. At the start of a new transaction, the client reads the cached server list to identify a member that has untapped capacity, and looks in the transport pool for an idle transport that is tied to the under-utilized member. (An idle transport is a transport that has no associated connection object.)
   • If an idle transport is available, the client associates the connection object with the transport.
   • If, after a user-configurable timeout, no idle transport is available in the transport pool and no new transport can be allocated because the transport pool has reached its limit, an error is returned to the application.
3. When the transaction runs, it accesses the member that is tied to the transport.

   When the first SQL statement in a transaction runs, if the IBM Data Server Driver for JDBC and SQLJ receives a communication failure because the data server drops the connection or the blockingReadConnectionTimeout value was exceeded, the driver retries the SQL statement once before it reports an error. On every retry, the driver closes the existing transport, obtains a new transport and then executes the transaction.

4. When the transaction ends, the client verifies with the server that transport reuse is still allowed for the connection object.
5. If transport reuse is allowed, the server returns a list of SET statements for special registers that apply to the execution environment for the connection object.

   The client caches these statements, which it replays in order to reconstruct the execution environment when the connection object is associated with a new transport.

6. The connection object is then disassociated from the transport.
7. The client copy of the server list is refreshed when a new connection is made, or every 30 seconds.
8. When workload balancing is required for a new transaction, the client uses the same process to associate the connection object with a transport.