How Application Continuity Works for Applications

Application Continuity operates on request boundaries. A request is a unit of work submitted by the application. It is normally executed between borrowing and returning connections for Universal Connection Pool, Oracle WebLogic Server, DRCP, and third-party connection pools. A request is marked by the beginRequest and endRequest APIs. Oracle Database provides these APIs, by default, when using one of the aforementioned connections pools.

Application Continuity works for applications, as follows:

1. You either create a new database service or modify an existing database service so that the -failovertype parameter is set to TRANSACTION, and the -commit_outcome parameter is set to TRUE.

   See Also:

   "Creating Services for Application Continuity and Transaction Guard"

2. When an application opens a connection to the database using this service or borrows a connection from an Oracle connection pool using this service, the session handle carries a logical transaction ID (LTXID) for each transaction.

3. When the application submits a request, the server and replay driver collaborate to determine what states are to be captured for replay if there is an outage. If a recoverable error occurs (planned or unplanned), then the error message is sent back to the replay driver.

4. For JDBC-thin (type 4) applications, the replay driver receives the FAN message (down or error). Fast Connection Failover (FCF) aborts the dead session. The replay driver then:

   1. Replaces the dead physical session with a new clean session and reestablishes FAN in case a later error occurs during or after replay.

   2. Uses Transaction Guard to determine the outcome of the in-flight transaction, if one was open, to prepare for replay.

   3. Optionally, calls back using a labeling callback or reconnect callback for the initial state, if one of these is registered.

   4. Rebuilds the database session, recovering the transactional and nontransactional states, and validating at each step that the data and messages seen by the client driver are the same as those that the client may have seen and potentially made a decision on.

5. Oracle Database validates replay when replay is initiated and as replay progresses. If the database session cannot be rebuilt correctly, because the client data cannot be repositioned to the same data values and messages that the client potentially made decisions on previously, then the replay driver returns the original error to the application.