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 ContinuityFor using Application Continuity, you must first configure your data source as described in "Data Source Configuration". After that, use one of the following two features for implementing Application Continuity in your applications using Universal Connection Pool (UCP) for JDBC:
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");
See Also:
"Using the Pool-Enabled Data Source"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 ContinuityWhen 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 informationConnection 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 connectionsConnection 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.
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 "Connection Initialization Callback".