Quant un enregistrement est changé, cette image n’est mise à jour qu’en mémoire. Dans certains cas, elle ira sur disque. Cependant, dès que cette image mémoire est mise à jour, le changement est effectué et le programme reprend le contrôle. À présent, ajoutons la journalisation locale à ce scénario.

Quand un enregistrement est changé dans un fichier journalisé, nous mettons d’abord à jour l’image en mémoire. Puis nous devons écrire l’entrée du journal sur disque. Rappelons que l’écriture sur disque reste l’opération la plus lente du System i. Cette écriture sur disque de l’entrée du journal dans le récepteur du journal, est ce qui ralentit les applications une fois que la journalisation à démarré. Le programme ne reprend le contrôle qu’une fois que l’image mémoire de l’enregistrement a été mise à jour et que l’entrée du journal a été écrite sur disque.

En quoi la journalisation à distance affecte cela ? L’effet est différent selon la méthode utilisée. La première méthode, la plus courante, consiste à envoyer les entrées de manière asynchrone. Ce faisant, nous mettons un jour l’image de l’enregistrement en mémoire, nous écrivons l’entrée du journal du côté local, nous mettons en files d’attente de l’entrée du journal pour l’envoyer au système à distance, puis nous redonnons la main au programme. On le voit, il y a juste un peu plus de travail pour mettre en file d’attente l’entrée à envoyer.

La seconde méthode d’envoi est le mode synchrone. La séquence est alors la suivante : mettre à jour l’image de l’enregistrement en mémoire, écrire l’entrée du journal sur disque côté local, et transmettre l’entrée du journal au système cible. Ce dernier écrit l’entrée du journal sur son disque et renvoie un accusé de réception au système source. Ce n’est qu’après l’arrivée de cet accusé de réception que le programme reprend le contrôle. La méthode synchrone allonge la durée de chaque mise à jour ou transaction. Avantage : le système cible est toujours en concordance avec le système source. Dans ce mode de communication asynchrone, chaque transaction n’est que légèrement alourdie par la mise en file d’attente.

Or, à cause de cette file d’attente, le système cible peut prendre du retard par rapport au système source : quelques secondes, minutes, ou… heures. Si vous ne pouvez pas attendre et si vous voulez être absolument sûrs de l’entrée sur les deux systèmes, utilisez les communications synchrones. Pour la plupart des clients, le ralentissement des applications est jugé trop important et ils tolèrent volontiers le léger retard dû à la file d’attente. Ils optent donc pour l’asynchrone.