1. Developer's Guide
  2. Features of Oracle Data Provider for .NET
  3. Application Continuity

Application Continuity

Oracle Application Continuity enables database requests to automatically replay transactional or non-transactional operations in a non-disruptive and rapid manner in the event of a severed database session, which results in a recoverable error. Application Continuity improves end-user experience by masking planned and unplanned related errors. Applications can be developed without complex logic to handle exceptions, while automatically replaying database operations upon a recoverable error.

Without Application Continuity, it is almost impossible to mask outages in a safe and reliable manner. Common issues encountered include:

  • The client state remains at present time, with entered data, returned data, and variables cached, while the database state changes are lost.

  • If a transaction commit has occurred, the commit message is not durable. Moreover, checking a lost request does not guarantee that it will not commit after being checked.

  • Non-transactional database session state is lost.

  • If the request can continue, the database and the client session must be synchronized.

Application Continuity is a feature available with the Oracle Real Application Clusters (RAC), Oracle RAC One Node, Oracle Active Data Guard, and Oracle Autonomous Database in both Shared and Dedicated Infrastructure.

In Oracle Database 18c, Application Continuity improves transparent session and transactional state tracking and recording of the database session to enable recovery following recoverable outages. This enhancement is called Transparent Application Continuity (TAC). TAC has no reliance on application knowledge or application code changes, allowing it to be enabled for your applications. ODP.NET application transparency and failover are achieved by consuming the state-tracking information that captures and categorizes the session state usage as the application issues user calls.

ODP.NET and Application Continuity

All ODP.NET provider types, core, managed, and unmanaged, support Application Continuity and Transparent Application Continuity.

Note:

Asynchronous ODP.NET does not support Application Continuity and Transparent Application Continuity.

With Application Continuity or TAC enabled, ODP.NET ensures all the application's executed statements are logged appropriately so that they can be replayed upon a recoverable error. This applies for all application SQL and PL/SQL, as well as any internal ODP.NET operations.

On the client side, Application Continuity or TAC is enabled by setting the ODP.NET connection string attribute, Application Continuity=true. The attribute is set to true by default.

If Application Continuity is set to true, but the database server does not enable Application Continuity or TAC, then ODP.NET will still create new connections. However, these connections will not be Application Continuity enabled.

Both Application Continuity and TAC can be used with ODP.NET connection pool by implicitly BeginRequest/EndRequest calls, as well as without ODP.NET connection pool, by explicitly calling BeginRequest/EndRequest calls.

See Also:

Application Continuity Work Requests

AC and TAC operate on request boundaries. A request is an application unit of work. Typically, it exists between when an application borrows and returns a database connection from the connection pool. All ODP.NET providers use this model by default to demarcate work request boundaries.

ODP.NET Core and managed ODP.NET include an additional capability for developers to explicitly identify request boundaries themselves using the OracleConnection BeginRequest and EndRequest methods. Preferably, applications will not need to use these methods and just rely on the default behavior. When a connection is checked out, ODP.NET implicitly calls BeginRequest. And when the connection is checked in, ODP.NET implicitly calls EndRequest. This model scales well and makes AC and TAC easier for developer use.

Applications that do not use ODP.NET connection pools should explicitly mark request boundaries, such as the case with custom connection pools. The BeginRequest method should be called upon connection check out and the EndRequest method should be called upon connection check in.

With an understanding of the request demarcation points, ODP.NET knows when it is safe to release the database call history. Proper request boundary identification conserves memory consumption for long living connections, such as when they exist in a custom pool.

These methods have no application impact other than improving resource consumption, recovery, and load balancing performance. They do not alter connection state by calling any method, SQL, nor PL/SQL.

If a begin or end request is made while a local transaction is open, ODP.NET returns an error.