Moniteur transactionnel

Le premier modèle vise à réserver des ressources pour chaque utilisateur et à dimensionner la machine en multipliant les ressources allouées pour chaque utilisateur par le nombre d'utilisateurs. Cette technique possède trois inconvénients majeurs :

• lorsque l'utilisateur ne travaille pas, les ressources sont réservées pour rien et elles sont inexploitables pour d'autres applications ;
• il n'est pas toujours possible de compter les utilisateurs pour leur réserver des ressources, notamment dans le cadre des applications de grande envergure ou des applications connectées au web ;
• cette façon de concevoir des applications engendre des achats matériels et logiciels de coûts prohibitifs et souvent disproportionnés par rapport à l'application (voir exemple).

Ce modèle est souvent réservé pour des applications de petite et moyenne taille. On trouve les applications en architecture deux tiers dans ce modèle.

Le concept du moniteur transactionnel vient du constat qu'une application ne peut répondre à chaque demande d'un client au moment exact où ce dernier soumet sa demande pour les trois raisons expliquées ci-dessus. Si une application répond de manière immédiate à chaque demande du client, elle met en péril le système sur lequel elle tourne dans la mesure où tous les clients peuvent potentiellement demander des transactions au même exact moment et donc saturer les ressources de la machine.

Le moniteur transactionnel va donc gérer un nombre dit maximum de transactions pouvant être exécutées en parallèle. C'est ce nombre (et non le nombre des utilisateurs) qui dimensionnera les caractéristiques de la machine. Entre chaque transaction, le moniteur transactionnel ne garde aucune mémoire de la transaction utilisateur qui vient de s'achever, si bien que chaque utilisateur ne coûte rien au système dès lors que ce dernier a achevé sa transaction.

Considérons un système R de ressources réservées. Nous dirons pour simplifier qu'une transaction T moyenne sur ce système consomme X ressources du système durant le temps de la transaction T. Si nous voulons que 4 000 utilisateurs travaillent sur ce système, nous dimensionnerons la machine à (4000.X) en termes de ressources système.

Considérons désormais un système équipé d'un moniteur transactionnel M. Nous imposerons les mêmes contraintes sur les 4000 utilisateurs voulant exécuter des transactions T consommant X à chaque fois. Nous estimerons que le temps moyen de la transaction sera de 1s et prendrons l'hypothèse que chaque utilisateur fera en moyenne 1 transaction T toutes les 15 secondes. Nous aurons donc un trafic moyen de 4000/15 = 267 transactions par seconde, soit une machine devant être dimensionnée à (267.X) en termes de ressources système, soit 15 fois moins que dans le modèle précédent.

L'utilisation d'un moniteur transactionnel est un élément des plus structurant de la conception d'une application informatique. Ainsi, on ne peut pas porter facilement n'importe quelle application sur un moniteur transactionnel (la plupart du temps, ces portages sont même impossibles et nécessitent une réécriture de l'application). De plus, la programmation dans un moniteur transactionnel impose un certain nombre de contraintes de conception et de contraintes techniques, ce qui rend la programmation parfois plus complexe.

Cependant, une application transactionnelle lourde ne saurait être implémentée sans une gestion fine du partage des ressources pour des raisons de fiabilité opérationnelle de l'application et d'économie de ressources machine.

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 phases.

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 chargé de lancer le commit ou le rollback global de la transaction, à la suite d'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.