Moniteur transactionnel - Définition

Un gestionnaire de ressources

En tant que moniteur, il pilote des systèmes gérant des transactions comme :

• les moteurs de base de données ;
• les systèmes de gestion des queues (souvent utilisées pour des communications asynchrones et/ou sécurisées) ;
• les systèmes de fichiers transactionnels (comme les bases de données séquentielles) ;
• etc.

Il peut aussi gérer les ressources systèmes utilisées par une application informatique :

• la mémoire vive ;
• le temps processeur ;
• plus généralement les ressources système de la machine comme :
  • la mémoire partagée ;
  • les ressources réseau ;
  • les pipe ;
  • les sémaphores ;
  • etc.

Une administration de haute qualité de l'application

Le moniteur transactionnel propose, la plupart du temps, une interface de monitoring de production de l'application en temps réel, ainsi que, suivant les cas, des stratégies pour réagir automatiquement à des erreurs de certaines transactions (dump, core) ou des brusques hausses du trafic transactionnel (allocation dynamique de ressources). La plupart des moniteurs sont robustes à des bugs applicatifs et ont une grande fiabilité en production.

Pilotage des moteurs de transactions par le moniteur

Coordination des différents moteurs transactionnels

Un moniteur transactionnel ne doit pas être confondu avec un système gérant les transactions. Dans la plupart des cas, le moniteur transactionnel ne gère pas directement les transactions mais pilote des moteurs transactionnels gérant différents types de transactions (voir par exemple la norme XA utilisée pour synchroniser les différents gestionnaires de transactions).

Par exemple, la responsabilité d'un moniteur dans le cadre d'une transaction peut être de synchroniser en tout ou rien une transaction base de données avec une transaction effectuée sur une queue. C'est cette transaction globale qui est à la charge du moniteur, et pour cela, ce dernier s'appuiera sur un moteur de base de données pour la gestion de la transaction base de données et sur un moteur de gestion des transactions sur les queues pour la seconde partie. Lorsque plusieurs pilotes transactionnels sont invoqués dans la même transaction informatique, se posent les problèmes classiques du commit à deux phase.

Partage des ressources a priori et instructions interdites

Pour illustrer ce pilotage, notamment du moteur transactionnel qui pilote une base de données, on trouve souvent dans les moniteurs transactionnels du marché le concept de pool de connexions à une base données. Le moniteur, dans le cadre de son activité de coordination, gère un ensemble fixe ou variable de connexions à la base de données et impose à chaque transaction d'utiliser une connexion du pool.

Toute création de connexion à la base de données (instructions coûteuses pour l'application) est donc interdite au niveau de la transaction elle-même (et donc au niveau du code applicatif), cette tâche étant réservée au moniteur transactionnel. Ce dernier est aussi en charge de lancer le commit ou le rollback global de la transaction, suite à un code retour normalisé renvoyé par le code applicatif de la transaction. Ainsi, le moniteur se réserve la gestion de certains ordres de pilotage du moteur de base de données en vue de gérer les ressources.

Dans cet exemple, il ne sera pas possible que l'application exécute de manière simultanée plus de transactions qu'il n'y a de connexions dans le pool. Les autres transactions seront mises en queue par le moniteur transactionnel. Certains moniteurs ont la capacité de s'adapter à une croissance subite de la demande pour éviter de mettre à mal les temps de réponse de l'application en plaçant en queue les transactions qui ne peuvent être exécutées.