Utilisez cette tâche pour permettre aux adaptateurs locaux optimisés d'exploiter le
support haute disponibilité.
Avant de commencer
L'adaptateur de ressource local optimisé
participe au support haute disponibilité de WebSphere
Application Server,
support qui offre la possibilité de spécifier le nom JNDI d'une fabrique de connexions secondaire
dans les propriétés personnalisées du pool de fabriques de connexions.
Important : Pour que le support haute disponibilité fonctionne correctement,
le nom du registre de ressources doit être spécifié sur la connexion gérée en utilisant
l'attribut Nom de registre de la fabrique de connexion à la fois pour la ressource principale et
pour la ressource secondaire. L'utilisation de la méthode setRegisterName()
empêche la ressource secondaire d'obtenir le contrôle.
Pour utiliser
le support haute disponibilité des adaptateurs locaux optimisés, effectuez les étapes
suivantes.
Procédure
- Ajoutez la propriété alternateResourceJNDIName aux propriétés de pool de connexions
d'une fabrique de connexions. Spécifiez le nom JNDI de la fabrique de connexions
de la ressource secondaire.
Par exemple, si votre élément JNDI principal est
eis/ola et que vous voulez désigner eis/ola_backup comme ressource
secondaire, attribuez la valeur eis/ola_backup à la propriété alternateResourceJNDIName
puis ajoutez cette propriété à une propriété de pool de connexions sur la fabrique de connexions
eis/ola.
- Pour que le basculement puisse avoir lieu, assurez-vous que l'espace adresse externe associé au nom d'enregistrement de la fabrique de connexions
secondaire est disponible.
Avec les adaptateurs locaux optimisés, le processus de basculement de ressource est déclenché lorsqu'une
application émet une demande
getconnection() sur une ressource et que cette demande échoue en raison de l'indisponibilité de l'enregistrement cible. Durant ce processus,
le nom JNDI de la ressource secondaire est utilisé en remplacement dans l'appel
getconnection(). Le nombre de tentatives infructueuses autorisées avant que le basculement ne soit déclenché peut être
configuré par l'ajout d'une autre propriété de pool de connexions, failurethreshold. Si vous réglez cette
propriété à 1, cela signifie que le basculement a lieu dès le premier échec. Autrement dit,
dès lors que l'obtention d'une connexion échoue (avec une ResourceException), les demandes suivantes sont
adressées à la fabrique de connexions secondaire.
Un événement de basculement déclenche un processus consistant à envoyer les demandes suivantes à la
ressource secondaire, avec le nom JNDI et le nom d'enregistrement secondaires. Simultanément, un processus
d'interrogation périodique démarre. Ce processus consiste, pour la gestion des connexions de WebSphere
Application Server,
à envoyer une demande toutes les 10 secondes afin de déterminer si la ressource principale est à nouveau
disponible. La gestion des connexions de WebSphere
Application Server peut
aussi envoyer un message au journal du serviteur (servant) WebSphere
Application Server indiquant
qu'il y a eu basculement sur la ressource secondaire, puis rebasculement sur la ressource principale. Vous pouvez
utiliser la propriété
failureNotificationActionCode du pool de connexions de la fabrique de connexions
pour spécifier la notification voulue.
La valeur par défaut de cette propriété est 1, ce qui signifie que des
messages sont envoyés au journal des travaux du serviteur. Pour plus d'informations,
référez-vous à la rubrique consacrée au routage de charge de travail des ressources source de
données et fabrique de connexions.
Lorsque l'adaptateur de ressource WOLA détecte que la ressource principale est à nouveau
disponible ou que le nom de registre est actif, une notification est envoyée à la gestion des connexions
de WebSphere
Application Server pour l'informer que les nouvelles demandes
portant sur le nom JNDI de la ressource principale peuvent être à nouveau routées vers la fabrique de connexions
principale. Comme la disponibilité de la ressource principale est vérifiée à
intervalles de 10 secondes, lorsque l'enregistrement principal est à nouveau actif, il peut s'écouler jusqu'à 10 secondes
avant que le basculement vers cet enregistrement ne soit effectif.
- Redémarrez le serveur. Après avoir ajouté la propriété alternateResourceJNDIName
ou toute autre propriété du pool de connexions, vous devez redémarrer le serveur pour que ces
propriétés soient prises en compte.