10 Ensuring Application Continuity

This chapter discusses the following concepts related to the Application Continuity feature of Oracle Database:

10.1 Overview of Ensuring Application Continuity with UCP

Oracle Database 12c Release 1 (12.1) introduces the Application Continuity feature that provides a general purpose, application-independent infrastructure. Application Continuity enables recovery of work from an application perspective, after the occurrence of a planned or unplanned outage that can be related to system, communication, or hardware following a repair, a configuration change, or a patch application.

See Also:

Oracle Database Development Guide for more information about Application Continuity

For using Application Continuity, you must first configure your data source as described in "Configuring the Data Source for Application Continuity". After that, use one of the following two features for implementing Application Continuity in your applications using Universal Connection Pool (UCP):

10.2 Configuring the Data Source for Application Continuity

To utilize the Application Continuity feature on a pool-enabled data source, the application must make the following call on oracle.ucp.jdbc.PoolDataSource interface:

// pds is a PoolDataSource
pds.setConnectionFactoryClassName("oracle.jdbc.replay.OracleDataSourceImpl");

Always connect to a service, instead of using SID. Application Continuity is not supported when connecting in the SID syntax.

See Also:

Oracle Database Development Guide for more information about Application Continuity

When running against Oracle Real Application Clusters (Oracle RAC) or Data Guard, the application should also enable Fast Connection Failover (FCF) as shown in the following code snippet:

pds.setFastConnectionFailoverEnabled(true);

See Also:

"Enabling Fast Connection Failover" for more information

10.3 Using Connection Labeling for Application Continuity

Connection labeling enables an application to attach arbitrary name/value pairs to a connection. The application can request a connection with the desired label from the connection pool.

See Also:

"Labeling Connections in UCP " for more information labeling connections

Connection labeling sets the initial state for each connection request. If the application uses connection labeling or benefits from labeling connections, then a labeling callback should be registered for Application Continuity to initialize clean connections at failover.

Every time Application Continuity gets a new connection from the underlying data source, the labeling callback executes. The callback executes during normal connection check-out and also during replay. So, the state that is created at run time is exactly re-created during replay. The initialization must be idempotent.

It is legal for the callback to execute a transaction as long as the transaction completes (either it commits or rolls back) at the end of callback invocation. Application Continuity repeats any action coded within the callback implementation, including such transaction. If an outage occurs during the execution of a UCP labeling callback, then Application Continuity may execute the callback more than once as part of the replay attempt. Again, it is important for the callback actions to be idempotent.

10.4 Using Connection Initialization Callback for Application Continuity

If an application cannot use connection labeling because it cannot be changed, then the connection initialization callback is provided for such an application.

When registered, the initialization callback is executed every time a connection is borrowed from the pool and at each successful reconnection following a recoverable error. For more information about using connection initialization callback, refer to "About Connection Initialization Callback".