Configure client reroute for applications that use DB2 databases

The client reroute feature enables us to configure the client applications for a DB2 universal database to recover from a communication loss, and the applications can continue to work with minimal interruption. Rerouting is central to the support of continuous operations, but rerouting is only possible when there is an alternate location that is identified to the client connection.

This task assumes the following:

• We have a DB2 data source defined in the application server. See the topic, Configuring a data source using the administrative console, for information about creating a data source.

• The DB2 data source to which the application connects is running one of the following:
  • DB2 for z/OS Version 10.1 or later
  • DB2 Database for Linux, UNIX, and Windows v9.7 or later

• We have implemented the DB2 database with a redundant setup or the ability to fail the DB2 server to a standby node.

• We are connecting to the data source with a Type-4 connection.

Client reroute for DB2 allows us to provide an alternate server location, in case the connection to the database server fails. If we decide to use client reroute with the persistence option, the alternate server information persists across Java Virtual Machines (JVMs). In the event of an application server crash, the alternate server information is not lost when the application server is restored and attempts to connect to the database.

Without any configuration on the client side, a JDBC driver for DB2 supports the client reroute capability, if it is enabled, when the driver makes an initial connection to the DB2 server. When the JDBC driver connects to a DB2 server that has an alternate server configured, the primary server sends information about the alternate server to the JDBC driver. If the connection to the primary server fails, the JDBC driver is able to reroute connections to the alternate server. If the client process crashes, however, the alternate server information is lost, and the client needs to connect to the primary server again. If the client cannot make an initial connection to the primary server, the client has no knowledge of the alternate server and cannot reroute.

To overcome this problem, we can configure a DB2 data source in the application server with the Alternate server name and Alternate port number fields, or with the clientRerouteAlternateServerName and clientRerouteAlternatePortNumber data source custom properties, to support client reroute even on the initial connection attempt. If the JDBC driver is not able to connect to the primary DB2 server, the information necessary for a client reroute is already present, and the JDBC driver can reroute the connection to an alternate server.

The data source custom property, enableClientAffinitiesList, changes the semantics of the clientRerouteAlternateServerName and clientRerouteAlternatePortNumber properties. To learn more about these properties, see the DB2 information center topic, Common IBM Data Server Driver for JDBC and SQLJ properties for all supported database products. To learn more about client affinity, see the topic, .Configuring client affinity for applications that use DB2 databases.

Additionally, if we have configured a DB2 data source as a Type 4 JDBC driver, we can use the Client reroute server list JNDI name field, or the clientRerouteServerListJNDIName data source custom property, to enable persistence of the client reroute state. Typically, when a connection is rerouted and the JDBC driver has connected to the alternate DB2 server, the alternate server sends information about its own alternate server to the JDBC driver. The JDBC driver will then have the information required to reroute the connection again if the alternate DB2 server is not available. Effectively, the server that was originally the alternate server is now the primary server, and a new alternate server has been established. If we enable persistence for client reroute, this new state can be remembered. If the application server crashes and is restarted, the JDBC driver can connect to the DB2 server that was considered the primary server at the time of the crash. Without the persistence feature, the JDBC driver would have to start from the original server configuration and attempt to connect to the server that was originally considered the primary server.

Use the automatic client rerouting feature within the following DB2 configurable environments:

• Enterprise Server Edition (ESE) with the data partitioning feature (DPF)
• Data Propagator (DPROPR)-style replication
• High availability cluster multiprocessor (HACMP™)
• High availability disaster recovery (HADR).

Tasks

1. In the administrative console, click...

           Resources > JDBC > Data sources > data_source.

2. Click WAS data source properties.

3. In the DB2 automatic client reroute options section, fill in the fields to enable client rerouting. Complete the following fields:

   Alternate server names

   List of alternate server name or names for the DB2 server. If more than one alternate server name is specified, the names must be separated by commas. For example:

    host1,host2
   

   Alternate port numbers

   List of alternate server port or ports for the DB2 server. If more than one alternate server port is specified, the ports must be separated by commas. For example:

   5000,50001
   

   Ensure an equal number of entries must be specified for both alternate ports and hosts. Otherwise, a warning is displayed and client reroute is not enabled.

4. Optional: Enable client reroute with the persistence option.
   1. Complete the field for Client reroute server list JNDI name. The field specifies the JNDI name used to bind the DB2 client reroute server list into the JNDI name space. The DB2 database server uses this name to look up the alternate server name list when the alternate server information is not already in memory.

      Be aware of the following:

      • This option is not supported for Type 2 data sources. If we use a DB2 data source configured as a Type 2 JDBC driver, the JDBC driver uses a catalog to persist the client reroute information. If this property is configured with a Type 2 driver, the application server will issue a warning.

      • Use different JNDI names among different data sources. Otherwise, when you delete a data source, and the JNDI entry is removed from the name space, the other data sources that share the JNDI entry will be affected.

5. Configure the retry count and interval for the client reroute function. Complete these two fields:

   Retry interval for client reroute

   Amount of time, in seconds, between retries for automatic client reroute.

   Maximum retries for client reroute

   Maximum number of connection retries that are attempted by the automatic client reroute function if the primary connection to the server fails. The property is only used when Retry interval for client reroute is set.

6. Click OK and save the changes.

7. Restart the application server.

What to do next

If we later want to remove the client reroute information that is bound in JNDI, we can do so by deleting the data source. We can also use the unbind feature with the test connection service to delete the JNDI binding for the client reroute function from the application server's JNDI name space without deleting the data source.

To delete the JNDI binding for client reroute:

1. Select Unbind client reroute list from JNDI.

2. Click OK.

3. Save the configuration.

4. Click Test connection for the data source.
5. Deselect Unbind client reroute list from JNDI.

6. Click OK.

7. Save the configuration.

Configure a JDBC provider and data source

Configure a data source

Configure client affinities for applications that use DB2 databases

Configuration of client affinities for Java clients for DB2 Database for Linux, UNIX, and Windows connections

IBM WebSphere Developer Technical Journal: Building a high availability database environment using WebSphere middleware, Part 1