DB2 Version 9.7 for Linux, UNIX, and Windows

Application programming requirements for high availability for connections from Java clients to DB2 for z/OS servers

Failover for automatic client reroute can be seamless or non-seamless. If failover for connections to DB2® for z/OS® is not seamless, you need to add code to account for the errors that are returned when failover occurs.

If failover is not seamless, and a connection is reestablished with the server, SQLCODE -30108 (SQL30108N) is returned to the application. All work that occurred within the current transaction is rolled back. In the application, you need to:

Check the reason code that is returned with the -30108 error to determine whether special register settings that were carried over from the failing data sharing member to the new (failover) data sharing member were the settings at the most recent commit point, or the settings at the point of failure. Reset any special register values that are not current.
Execute all SQL operations that occurred since the previous commit operation.

The following conditions must be satisfied for seamless failover to occur for direct connections to DB2 for z/OS:

The application language is Java™, CLI, or .NET.
The connection is not in a transaction. That is, the failure occurs when the first SQL statement in the transaction is executed.
The data server allows transport reuse at the end of the previous transaction. An exception to this condition is if transport reuse is not granted because the application was bound with KEEPDYNAMIC(YES).
All global session data is closed or dropped.
There are no open, held cursors.
If the application uses CLI, the application cannot perform actions that require the driver to maintain a history of previously called APIs in order to replay the SQL statement. Examples of such actions are specifying data at execution time, performing compound SQL, or using array input.
The application is not a stored procedure.
The application is not running in a Federated environment.
Two-phase commit is used, if transactions are dependent on the success of previous transactions. When a failure occurs during a commit operation, the client has no information about whether work was committed or rolled back at the server. If each transaction is dependent on the success of the previous transaction, use two-phase commit. Two-phase commit requires the use of XA support.