FAN vs TAF Mail de Gérard Bouaziz

, par  Olivier Duquesne aka DaffyDuke , popularité : 1%

Non ni TAF ni FAN(FCF) ne rejouent les transactions DML (insert/update/delete) il faut les reprogrammer, mais ce n’est pas une obligation. Seul TAF permet la reconnection automatique

du client et uniquement sur une Query si configuré (pas DML) FAN ne le fait pas car FAN est un mecanisme programmatique

TAF permet le rejeu d’un select automatiquement si configuré, mais en réalité ne sert qu’en DataWarehouse lors de select conséquents. Je le configure ici pour éviter sa reprogrammation

donc il sera utile et utilisé pour les transactions de type Query

Une totale transparence transactionnelle est l’idéal mais il faut bien voir que sa programmation n’est pas des plus simple dans les deux cas (FAN ou TAF) : il faudrait que les developpeurs

par exemple puissent encapsuler une connexion database dans une classe spéciale pour les transaction en failover et dans une autre classe pour une logique sans failover s’ils veulent

categoriser les transactions à rejouer par exemple.

De plus la gestion des événements doit être maîtrisée et elle ne pourra se faire qu’au prix de tests sur une plateforme "crashable".

Je ne pense pas que la décision du rejeu d’une transaction dépende uniquement du développement mais soit de plus haut niveau.

Que cela soit TAF ou FAN la non prise en compte d’un code retour s’l ’est pas correctement trappée par l’exception correspondante terminera le programme.

La base commence toujours par défaire(rollback) les changements non commités (l’ instance restante) une erreur sera remontée au client qui devrait à son tour faire son propre rollback.

Une seconde erreur est remontee pour indiquer que la connexion est perdue. Cette erreur là devra être trappée si l’on souhaite rejouer la transaction.

FAN

La difference entre TAF et FAN est notée ici :

 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. => Avec FCF c’est à la charge du developpeur de se reconnecter. Avec TAF c’est automatique.

 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.

FAN repose sur ONS (oracle notification service) qui permet la notification des évnemenents remonté par EVMD. ONS est deja configure sur les noeud du cluster et nécessite

une configuration supplementaire sur le middle pour être activé.

Il faut noter une difference essentielle entre TAF et FAN à savoir que FAN remonte les informations d’etat directement au niveau applicatif (push) alors

que TAF se contente de faire du polling (client). FAN est donc beaucoup plus réactif. FAN peut neanmoins être integre avec TAF

Pour programmer FAN il est possible d’utiliser soit C soit Java. Ensuite on peut utiliser soit ONS API C soit ONS Java API soit

implicit cache connection de JDBC et FCF et laisser la gestion des evenement FAN par la librairie JDBC (jdbc)(JDBC-OCI ou jdbc thin) ce qui evite d’avoir a gerer l’API ONS directement.

Dans le dernier cas il y a toujours une gestion des evenements mais FAN mais est plus "souple" à programmer.

DBCP fonctionne avec Oracle Cache connection et FCF (Fast Connection Failover) dans sa version actuellement implantée sur nos serveurs. Il faut activer implict cache connection et FCF.

TAF

On peut néanmoins s’éviter la programmation FAN en utilisant les callback et l’interface OracleOCIFailover pour programmer le rejeu du DML.

Il faut implementer la fonction callback fourni par la classe OracleOCIFailover

Dans une transaction classique :

Registrer la fonction callback : => registerTAFCallback()

Enfin la fonction callback (que j’ai remis dans un exemple complet mais dont la premiere partie n’est la que pour montrer le register de la callback)

La seconde partie montre l’implantation de la callback.

L’implementation de la callback n’est pas obligatoire si on ne veut pas rejouer du DML mais elle peut être là pour logger le comportement du failover OU permettre

de redemander une connexion en cas de probleme du failover ou bien d’aborter la demande. Dans ce cas precis FO_ERROR = 5 l’application peut redemander une reconnexion

du nombre de fois spécifié par le parametrage de tnsnames.ora (RETRIES) je pense et sleep pendant le temps indique dans le programme

si specifié (ou parametre DELAY ?)

La doc oracle n’etant pas tres precise et prolixe en la matiere cela est à tester.

Les points d’interrogation sont le comportement du programme en cas FO_ERROR = 5. Le comportement de TAF est de recreer une connexion automatiquement en cas de failover sur une query pas sur DML . Dans le cas ou l’on implémente une Query c’est TAF via tnsnames qui automatiquement recrée une connexion mais rien

n’interdit d’aborter le retry dans le cas FO_ERROR = 5, il suffit de ne pas envoyer un FO_RETRY.

L’exemple que je fournis est sur du DML et c’est à la charge du programme de redemander une connexion via la fonction handleDBConnections()) si souhaité

Dans ce cas je pense aussurement que le parametre RETRIES et DELAY ne sont plus geres par tnsnames mais par l’application qui doit elle meme gerer ses compteurs de retry et de sleep

Encore une fois on peut aborter le nombre de retries dans le cas du FO_ERROR si souhaité.

Enfin la doc n’est pas tres claire s’il faut fournir un rollback au niveau applicatif ou pas (comme je l’ai indiqué dans la fonction runQuery())

Note :

Driver-type dependency : TAF is in fact a OCI failover mechanism exposed to Java through JDBC-OCI. FCF is driver-type independent (i.e., works for both JDBC-Thin and JDBC-OCI).

Publications Derniers articles publiés