C’est aussi une méthode séduisante pour accroître le parallélisme du côté cible pendant le traitement replay continu d’une solution HA par réplication logique. Ce faisant, on aide le côté cible à tenir le rythme (deux replay threads en parallèle valent mieux qu’un seul). Bien que l’idée du parallélisme soit alléchante, elle présente un inconvénient potentiel, particulièrement si les deux fichiers sont apparentés.

Prenons l’exemple d’une application bancaire qui transfère des fonds entre vos deux fichiers physiques (FP) : compte épargne vers compte chèques. Si le FP compte épargne envoie ses changements au journal N° 1 pendant que le FP compte chèques est en train de parler au journal N° 2, vous risquez une surcharge en coulisses pour coordonner ces changements journalisés séparément dans une transaction unique. Si vous utilisez le contrôle d’engagement (commitment control) après chaque transaction, le système d’exploitation devra procéder à un traitement supplémentaire et à des étapes de coordination pour confirmer que les deux journaux sont prêts à signaler et à enregistrer une limite de cycle commit. En réalité, c’est vous qui assumerez le contrôle d’engagement en deux phases.

La règle en la circonstance est simple : si deux FP associés risquent d’être changés dans la même transaction commit, assurez-vous que les deux FP parlent au même journal.

En corollaire, vous devez de la même manière éviter d’utiliser deux journaux si les deux FP sont référencés par un fichier logique indexé multiformat partagé. Si la logique indexée rencontre deux journaux sous-jacents distincts, elle voit sa personnalité divisée, ce qui la rend inéligible à la protection du chemin d’accès géré par le système. En fin de compte, vous subirez des étapes de reprise IPL anormales excessivement longues.

Moralité : tenez les fichiers physiques apparentés associés au même journal.