Oracle .NET Application Continuity — Getting Started
One frequent request I hear is for ODP.NET sample code using Oracle Application Continuity (AC). It usually comes from customers trying ODP.NET AC for the first time. I put together a running ODP.NET AC code sample for anyone to try in a proof of concept evaluation to get started. The sample code can be run against a single instance database to keep the setup simple. The comments section contains all the client side and database configuration instructions needed to successfully test AC out.
2024 Update: Managed ODP.NET and ODP.NET Core 23c now support AC and Transparent Application Continuity (TAC) with Oracle Database 19c and higher. This blog, the sample code, and the ODP.NET 23c Application Continuity documentation have been updated to reflect the new support.
Oracle Application Continuity Introduction
Of course, if you’re not familiar with Oracle Application Continuity, you are wondering what it is. Let me introduce the feature and why so many Oracle Database users and .NET developers want to adopt it.
For several years, Oracle has been talking about continuous availability rather than just high availability. Continuous database availability is when planned and unplanned outages are hidden from the end user. While software and hardware outages still occur, systems are resilient such that the end user experiences no errors, loses no work, and continues on using the database application. The end user need not be aware that events, such as a software update, machine outage, or load imbalance in the database tier occurred.
On the database side, Oracle Real Application Clusters (RAC) and Oracle Data Guard have been around a long time to provide robust database availability solutions. A remaining architectural availability challenge is to ensure the client application remains just as available when an outage in the database tier occurs. Availability must be end-to-end to be truly effective. Equally important, maintaining availability should not require code nor configuration changes when the application or database business logic changes. That’s where AC comes in and shines.
AC 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. AC improves the end user experience by masking planned and unplanned outage errors. Applications can be developed without complex logic to handle exceptions, while automatically replaying database operations upon a recoverable error.
In fact, ZERO application code changes are necessary to use AC. ODP.NET actually enables it on the client side by default via the connection string attribute:
Application Continuity=true
Any existing ODP.NET application can be AC-enabled as soon as the database server is configured for AC.
Without AC, it is almost impossible to mask outages in a safe and reliable manner. The database may lose state changes the client attempts to make. Even worse, the end user may not know whether a transaction committed because the commit message was not durable.
AC is available with Oracle RAC, Oracle RAC One Node, Oracle Active Data Guard, and both dedicated and shared Oracle Autonomous Database.
Testing ODP.NET Application Continuity
If you would like to try ODP.NET AC yourself, use the sample code I linked to at the beginning of this post. The code uses the well-known Oracle HR sample schema. The app loops infinitely incrementing one employee’s salary in a local transaction.
While the app runs, connect to the database separately as an administrator. Intermittently execute the following command (after adding your database service name):
Execute dbms_service.disconnect_session(‘your service name’, dbms_service.immediate );
This command disconnects the user’s session, simulating a recoverable error condition. With AC enabled, the end user observes no error message, only a slight delayed execution. The app continues on without noticeable interruption to the end user’s work. AC has masked the outage from the end user and completes the transaction.
Setting up the ODP.NET AC Sample App
- Download the ODP.NET sample code into a .NET console project. Use .NET Framework for managed ODP.NET or unmanaged ODP.NET. Use .NET (Core) for ODP.NET Core.
- Modify the following connection string attributes, User Id, Password, and Data Source as needed.
- If you are using unmanaged ODP.NET, comment out the following line, such as:
//using Oracle.ManagedDataAccess.Client;
Then uncomment the following line, such as:
using Oracle.DataAccess.Client;
That’s all for the .NET code setup! It’s pretty simple. Now, run the app and follow the runtime instructions in the code comments to see ODP.NET AC and TAC in action.
Be sure to use managed ODP.NET or ODP.NET Core 23c or higher, which supports AC. For unmanaged ODP.NET, use version 12.2 or higher. I recommend using the highest ODP.NET version possible as we are constantly improving AC capabilities and fixing bugs.
Setting up the Database
- Connect as a database administrator to setup the HR schema if not already present. Some Oracle database server installations include the create script in the following directory: %ORACLE_HOME%\demo\schema\human_resources\hr_main.sql
- Run “GRANT execute on DBMS_APP_CONT to HR;” so that ODP.NET can determine the in-flight transaction status following a recoverable error.
AC was first introduced in Oracle Database 12c. I recommend using the highest Oracle Database version available as well.
Conclusion
That’s it! You are now ready to run the app and test ODP.NET AC out.
As I said before, no application code changes are needed. The database setup instructions are simple. You can turn AC on for existing apps by enabling it on the database server.
