cal transaction. The cache manager then cleans up all invalid connections. When an application holding an invalid connection tries to do work through that connection, it is possible to receiveSQLException, ORA-17008, Closed Connection.
When an application receives a Closed Connection error message, it should do the following:
Retry the connection request. This is essential, because the old connection is no longer open.
Replay the transaction. All work done before the connection was closed has been lost.
Note:
The application should not try to roll back the transaction. The transaction was already rolled back in the database by the time the application received the exception.
How It Works
Under Fast Connection Failover, each connection in the cache maintains a mapping to a service, instance, database, and host name.
When a database generates an Oracle RAC event, that event is forwarded to the JVM in which JDBC is running. A daemon thread inside the JVM receives the Oracle RAC event and passes it on to the Connection Cache Manager. The Connection Cache Manager then throws SQL exceptions to the applications affected by the Oracle RAC event.
A typical failover scenario may work like the following:
A database instance fails, leaving several stale connections in the cache.
The RAC mechanism in the database generates an Oracle RAC event which is sent to the JVM containing JDBC.
The daemon thread inside the JVM finds all the connections affected by the Oracle RAC event, notifies them of the closed connection through SQL exceptions, and rolls back any open transactions.
Each individual connection receives a SQL exception and must retry.
Comparison of Fast Connection Failover and TAF
Fast Connection Failover differs from Transparent Application Failover (TAF) in the following ways:
Application-level connection retries
Fast Connection Failover supports application-level connection retries. This gives the application control of responding to connection failovers. The application can choose whether to retry the connection or to rethrow the exception. TAF supports connection retries only at the OCI/Net layer.
Integration with the implicit connection cache
Fast Connection Failover is well-integrated with the implicit connection cache, which allows the Connection Cache Manager to manage the cache for high availability. For example, failed connections are automatically invalidated in the cache. TAF works at the network level on a per-connection basis, which means that the connection cache cannot be notified of failures.
Event-based
Fast Connection Failover is based on the Oracle RAC event mechanism. This means that Fast Connection Failover is efficient and detects failures quickly for both active and inactive connections.
Load-balancing support
Fast Connection Failover supports UP event load balancing of connections and run-time work request distribution across active Oracle RAC instances.