Partager via


validation en deux temps

Une opération de logique métier donnée peut impliquer l’exécution de plusieurs programmes sur plusieurs ordinateurs. Dans cette conception, la transaction n’est pas considérée comme complète tant que tous les programmes impliqués n’ont pas terminé correctement leur exécution. Pour que ces programmes vérifient que tous les autres programmes qui font partie de la transaction ont terminé leurs transactions, ils doivent utiliser le protocole de validation en deux temps (2PC).

Le terme transaction (ou l’un de ses dérivés, comme transactionnel), peut être trompeur. Dans de nombreux cas, le terme transaction décrit un programme unique s’exécutant sur un ordinateur central qui n’utilise pas le protocole 2PC. Dans d’autres cas, toutefois, il est utilisé pour désigner une opération effectuée par plusieurs programmes sur plusieurs ordinateurs qui utilisent le protocole 2PC.

Le protocole 2PC est nommé ainsi car il utilise les deux phases suivantes avant de valider l’opération effectuée :

  • Phase 1 : Préparation. Au cours de cette phase, chacun des programmes impliqués dans la transaction envoie un message au gestionnaire TP, comme Microsoft Distributed Transaction Coordinator (MS DTC), en informant le gestionnaire TP qu’il est prêt et en mesure d’effectuer sa partie de l’opération. Cette phase est également connue sous le nom de préparation, car les programmes sont préparés pour valider les modifications ou restaurer les modifications. Si le gestionnaire TP reçoit une confirmation de chaque programme impliqué, il passe à la phase 2.

  • Phase 2 : Validation ou restauration. Au cours de cette phase, le gestionnaire TP demande à chacun des programmes de valider ou de restaurer toutes les modifications qui ont été demandées dans le cadre de la transaction. Une restauration correctement exécutée doit rétablir l’état d’origine du système.

Notes

L’état entre la phase 1 et la phase 2 est appelé état incertain. Les développeurs qui utilisent .NET dans leurs applications peuvent décider quelles parties de l’application requièrent l’accès à un TP et celles qui n’en ont pas besoin. TI étend également ce choix à l’ordinateur central, en gérant les appels qui requièrent des transactions et ceux qui n’en requièrent pas. Pour les applications qui requièrent une intégration complète entre la validation en deux temps basée sur Windows et les transactions de synchronisation de niveau 2 basées sur un ordinateur central, TI offre toutes les fonctionnalités nécessaires. TI fait cela sans que vous ayez besoin de modifier l’application cliente, sans placer de code exécutable sur l’ordinateur central et avec peu ou pas de modification des TP de l’ordinateur central. L’application cliente n’a pas besoin de faire la distinction entre le composant TI et toute autre référence de composant.

L’illustration suivante montre comment une application cliente Windows utilise implicitement Microsoft Distributed Transaction Coordinator (DTC) pour coordonner la validation en deux temps d’une transaction distribuée impliquant SQL Server et un TP CICS. DTC coordonne les transactions 2PC.

Image montrant une application cliente utilisant l’intégrateur de transactions et DTC pour coordonner une validation en deux phases entre SQL Server et une application CICS.
Application cliente utilisant Transaction Integrator et DTC pour coordonner une validation en deux phases entre SQL Server et une application CICS

Notes

Transaction Integrator prend en charge 2PC uniquement lors de la connexion à un ordinateur central via LU6.2 (APPC) avec Windows Initiated Processing. En cas de connexion directe via TCP/IP, aucune prise en charge de 2PC n’est disponible via TI.

Application cliente utilisant TI et DTC

Les transactions de validation en deux temps (2PC) impliquent un certain nombre de composants. Pour utiliser correctement Transaction Integrator (TI), vous devez comprendre les composants et la terminologie de 2PC suivants :

Point de synchronisation de niveau 2
Les TP peuvent interagir entre eux à l’aide du protocole LU6.2 à l’un des trois niveaux de synchronisation : synchronisation de niveau 0, de niveau 1 ou de niveau 2. Un seul de ces trois niveaux de synchronisation, le niveau de synchronisation 2, utilise le protocole 2PC. Le niveau de synchronisation 0 n’a aucune intégrité de message, tandis que le niveau de synchronisation 1 offre une prise en charge limitée de l’intégrité des données.

Gestionnaire TP
Le gestionnaire de programme transactionnel (TP) est un service système chargé de coordonner le résultat des transactions afin d’atteindre l’atomicité. Les gestionnaires TP s’assurent que les gestionnaires de ressources arrivent à une décision cohérente quant à la validation ou l’abandon de la transaction. Le gestionnaire TP Windows est MS DTC.

Service de resynchronisation
Le service de resynchronisation LU6.2 est un composant de Host Integration Server qui fonctionne avec MS DTC pour effectuer une récupération automatique à un état cohérent à la suite d’échecs à tout moment dans une transaction 2PC. Le service de resynchronisation LU6.2 est installé par défaut lors de l’installation de Host Integration Server.

Gestionnaire de ressources
Le gestionnaire de ressources est un service système qui gère les données durables. Les applications serveur utilisent des gestionnaires de ressources pour maintenir l’état durable de l’application, par exemple un enregistrement du stock disponible, des commandes en attente et des comptes clients. Les gestionnaires de ressources travaillent en coopération avec le gestionnaire de transactions pour fournir à l’application la garantie de l’atomicité et de l’isolation (en utilisant le protocole 2PC). Microsoft SQL Server™ et TI sont des exemples de gestionnaires de ressources.

Voir aussi

Transactions Windows et transactions d’ordinateur principal
Traitement transactionnel en ligne