Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

Data Provider for .NET Developer's G… Search

Database / Oracle / Oracle Database / Release ��

Developer's Guide

List of Examples
 On This Page 
 List of Tables Application Application Continuity

Title and Copyright Information Continuity ODP.NET and Application

 Continuity
Preface Oracle Application
 Continuity enables
Changes in This Release for Oracle
database requests to
 Data Provider for .NET
automatically replay
� Introducing Oracle Data Provider for transactional or non-
 .NET
transactional operations
� Installing and Con�guring Oracle in a non-disruptive and
 Data Provider for .NET rapid manner in the event
of a severed database
� Features of Oracle Data Provider for
 .NET session, which results in a
recoverable error.
Base Classes, Provider Factory Classes,
Application Continuity
and DbDataSource
improves end-user
Code Access Security experience by masking
planned and unplanned
Connecting to Oracle Database
related errors.
Real Application Clusters and Global Data Applications can be
Services developed without
complex logic to handle
Using Transaction Guard to Prevent
Logical Corruption exceptions, while
automatically replaying
Application Continuity database operations
upon a recoverable error.
Transparent Application Failover

Without Application
Oracle Globally Distributed Database
Continuity, it is almost
OracleCommand Object 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

1 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

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 ��c,

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

2 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

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 se�ing

3 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

the ODP.NET connection

string a�ribute,
Application
Continuity=true. The
a�ribute 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

• Or
acl
e
Ca
ll
Int
erf
ac
e
De
vel
op
er'
s
Gu
id
e
• Or
acl
e
Re

4 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

al
Ap
pli
ca
tio
n
Cl
us
ter
s
Ad
mi
nis
tra
tio
n
an
d
De
pl
oy
m
en
t
Gu
id
e
• Or
acl
e
Da
ta
ba
se
Hi
gh
Av
ail
ab
ilit
y
Ov
er
vie
w
an
d
Be
st
Pr
ac
tic
es
for
m
or
e
inf
or
m
ati

5 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

on
ab
ou
t
Hi
gh
Av
ail
ab
ilit
y
Ov
er
vie
w
an
d
Be
st
Pr
ac
tic
es
-
Co
n�
gu
rin
g
Le
vel
�:
M
as
k
Un
pl
an
ne
d
an
d
Pl
an
ne
d
Fai
lov
er
s
fro
m
Ap
pli
ca
tio
ns.

Application
Continuity Work

6 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

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

7 de 8 03/07/2025, 01:51 p.m.

Developer's Guide https://docs.oracle.com/en/database/oracle/oracle-database/23/odpnt/fe...

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
identi�cation 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.

 Previous Page

Next Page 

© Oracle About Oracle Contact Us Products A-Z Terms of Use & Privacy Cookie Preferences Ad Choices

8 de 8 03/07/2025, 01:51 p.m.