Database Reference
In-Depth Information
Essentially, Active GridLink is an important tool to implement FCF, runtime load balancing, and transaction
affinity. If your application uses WebLogic as a web server, you should implement Active GridLink-based data sources
to maximize the failover capabilities of RAC.
Transaction Guard (12c)
A key problem with failure detection and failure recovery is that the response from the database to the application is
transient. So, the response to a COMMIT statement can be lost in the case of instance failures. For example, consider
a scenario in which an application modified some rows and sent a commit to the database, but the database instance
failed and the application did not receive any response from the database. Hence, the application does not know
about the transaction status as the response from the database was lost. Two unique scenarios are possible:
1.
Database committed the changes, but success response was not received by the
application.
2.
Database failed even before the successful commit operation, and so the application must
replay the changes.
In either scenario, the application must know the transaction status to avoid data corruption. A new feature in
version 12c is the Transaction Guard, which provides a mechanism to keep track of the transaction state even after
database failures.
The Transaction Guard feature introduces the concept of logical transaction identifier. A logical transaction_id is
unique for a specific task from a connection, and the logical transaction_id is mapped to a database transaction_id.
The outcome of the logical transaction_id is tracked in the database. If there is a failure in the database, then
application connection can query the transaction status using logical transaction_id to identify if a transaction is
committed or not.
To implement this feature, you need to create a service with two attributes, namely,
commit_outcome
and
retention
. The commit_outcome attribute determines whether the logical transaction outcome will be tracked
or not. Attribute retention specifies the number of seconds a transaction outcome will be stored in the database
(defaults to a value of 86,400 seconds = 1 day). The following command shows an example of po service creation with
commit_outcome set to TRUE, enabling Transaction Guard.
$ srvctl add service -db orcl12 -service po -preferred oel6vm1 -available oel6vm2 \
-commit_outcome TRUE -retention 86400
The Transaction Guard feature requires code changes, and your application code must be changed to react at the
onset of failure. Application code must perform the following actions at the time of failure:
1.
Receive FAN events from ONS daemon for failures.
2.
Get the last logical transaction_id by calling getLTXID from a failed session.
3.
Retrieve the status of the logical transaction_id by calling GET_LXID_OUTCOME, passing
the logical transaction_id retrieved in step 2.
4.
Handle the transaction depending upon the transaction state.
Application Continuity (12c)
Application Continuity is a new feature implemented using the Transaction Guard feature. Oracle introduces a
new client-side JDBC driver class to implement Application Continuity. Universal Connection Pool and WebLogic
Active GridLink support Application Continuity by default. If your application uses a third-party connection pool
mechanism, then you need to modify code to handle Application Continuity.
