Database Reference
In-Depth Information
FCF and ONS
The architecture that Oracle uses to send events about the state change of each node to interested listeners is the ONS.
This is required for using FCF. ONS daemons reside on all the nodes. Whenever the state change occurs, the server
sends asynchronous notifications to all other ONS daemons (servers and clients, illustrated in Figure 15-2 ) and the
JVM (Java virtual machine) where the JDBC (Java Database Connectivity) application is running.
How Does the JDBC Application Get These Notifications?
To understand the behavior of all components of FAN and FCF, we discuss this through a scenario:
The setFastConnectionFailoverEnabled method is used to enable FCF.
1.
2.
The connection cache manager starts the failover event-handler thread. This happens
every time a connection cache is created.
3.
The event-handler thread subscribes to ONS events of type “database/event.”
4.
When an event or state change occurs on any of the nodes on the database server,
ONS daemon sends a notification of the following structure to all clients registered with
the daemon:
<Event_Type> VERSION=<n.n> service=<serviceName.dbDomainName>
[database=<db_unique_name> [instance=<instance_name>]] [host=<hostname>]
status=<Event_Status> reason=<Event_Reason>[card=<n>] timestamp=<eventDate>
<eventTime>
5.
ONS daemon on the client server receives this notification.
6.
The instance name indicates whether a specific instance is down or if the entire service is
down. If the instance value is null, it indicates that the entire service is down. If a specific
instance is down, it is identified by the instance name. Applications that have connections
to the instance that failed will roll back all open transactions.
The application will receive a connection-closed exception ORA-17008 . The application is
responsible for handling the errors.
7.
8.
When the last of the connection caches are closed, the connection cache manager
terminates the event-handler thread by calling the connection close () method to release
the connection back to the cache. On receiving the node down event, all connections in a
connection cache that are on the node that went down are removed.
9.
The cache is refreshed with new connections to the stable/backup node. When the cache
is refreshed, the initial properties used to create the cache are used.
10.
When the failed node is brought back online, the subscriber receives the notification, and
the cache distributes the connections to load balance the connections.
FCF message traffic can be tuned using the parameters that influence the notification services, described
in Table 15-2 .
 
Search WWH ::




Custom Search