Discussion:Moniteur transactionnel

	Tâches à accomplir pour Moniteur transactionnel	aide
	Votre aide est la bienvenue pour corriger les liens, présents dans l'article, vers les pages d'homonymie XA ⇒ Quelques explications pour effectuer ces corrections. -- 17 juillet 2019 à 16:09 (CEST)

Beaucoup d'ajouts ont été faits, assez pertinents dans l'ensemble, mais il serait souhaitable de les sourcer. Il me semble qu'il manque à présent une partie concernant la gestion des conflits de ressources (deadlock, commit,...) qui figurait dans une version précédente de cet article. D'autre part le terme de "Rationale" dans le titre du paragraphe 3 est un mot anglais, ne pourrait-on le traduire par "Principe" ou "Logique de fonctionnement"? -- Speculos (d) 23 février 2009 à 11:30 (CET)

Bonjour Spéculos,

Je m'attendais à ces questions, mais je suis parti en voyage une semaine donc me voilà apte à répondre.

En ce qui concerne le fait de citer ses sources, ça va être difficile. Disons que j'ai développé du middleware durant des années, des moniteurs notamment, et que j'ai utilisé la plupart de ceux du marché. J'ai fait des cours sur l'informatique transactionnelle aussi dans des grosses boîtes de software, donc je connais le sujet. J'imagine que pour faire bien, je pourrais citer les IBM red books qui sont la référence à la fois de l'esprit et de l'implémentation des moniteurs TP. IBM a tout inventé dans le domaine et CICS est conceptuellement bien mieux fait que Tuxedo que je trouve pourtant un très beau produit. Donc, pas le temps pour le moment de citer les sources mais je le note dans ma to do list.

De mon expérience des moniteurs transactionnels, la notion de gérer les conflits d'accès aux ressources est un peu externe au moniteur. En effet, le moniteur transactionnel est un pilote de moteurs de transactions, mais très exceptionnellement un moteur transactionnel en lui-même. En gros, le moniteur gère la synchro des commits et rollbacks dans les mécanismes du commit à deux phases, mais pas directement la transaction individuelle. Ainsi, derrière un EXEC CICS COMMIT, on trouve des appels au moteur de base de données (DB2), aux queues et aux systèmes de fichiers touchés par la transaction, mais pas de code gérant la transaction elle-même. On ne peut donc pas parler de deadloack pour un moteur qui appelle des gestionnaires de transactions. On peut le faire directement pour un moteur de base de données. En effet, tu peux demander à Oracle à d'update A puis B dans une transaction et B puis A dans une autre et tout locker. Le gestionnaire de transactions doit voir que deux transactions accèdent aux mêmes ressources, mais le moniteur lui ne voit que deux ordres à des moteurs externes. Ainsi à ma connaissance, quand le deadlock est repéré, il l'est pas le moteur transactionnel et non pas le moniteur TP. Le moniteur TP est un gros scheduler un peu malin et permettant de servir en masse, mais il ne gère pas directement la transaction ACID (sauf dans certains cas de commit à deux phases mais là encore, il agit en coordinateur). Par contre, on peut conserver ces notion dans les éléments connexes.

Tu as raison, rationale est un terme utilisé en anglais. Je pensais que c'était un terme latin... On peut le virer et mettre quelque chose comme principe ou logique de fonctionnement.

En fait, je suis un peu désolé, par manque de temps, j'ai viré plein de trucs sans proposer de restructuration. Je pense qu'il y a de la place pour le texte que tu avais placé mais plutôt sous la dénomination moteur transactionnel. C'est pourquoi depuis longtemps je voulais faire un article "informatique transactionnelle" plsu globale pour introduire les différentes notions. Un moteur de gestion des transactions est concerné par la logique des commit/rollback/deadlock/replay, et plus généralement point de synchronisation. Il gère des buffers, les locks physiques et logiques, des ressources en direct. Il peut ou non respecter la norme XA qui est une usine à gaz mais qui est pas mal dans le monde Unix pour faire du two phase commit. Là aussi, sur le sujet, ça vaudrait un article détaillé.

1001nuits (d) 28 février 2009 à 17:17 (CET)

Merci pour cette longue réponse... J'ai moi aussi une longue expérience (plus de 15 ans) du transactionnel, mais dans un environnement qui n'est pas IBM. Il me semble qu'il faut éviter d'être trop spécifique et lié aux concepts d'un constructeur. Dans le monde Bull il y a l'excellent moniteur transactionnel TP8 qui n'a pas les mêmes caractéristiques que CICS, et qui gère les transactions, rollback, deadlocks, etc... Essayons de faire un article plus général sans trop coller aux particularités (plus facile à dire qu'à faire), ou mieux on pourrait enrichir l'article avec les caractéristiques des principaux moniteurs du marché par exemple. Bonnes contributions! -- Speculos (d) 28 février 2009 à 19:23 (CET)