Traitement des transactions avec validation en deux phases

Cette rubrique décrit ce qui se passe avec la transaction de validation en deux phases (2PC) pendant qu’elle est traitée par Microsoft Distributed Transaction Coordinator (DTC) dans COM+, Transaction Integrator (TI) et CICS.

Le processus commence lorsque l’application cliente appelle une méthode sur l’application .NET qui contient l’objet TI. .NET alloue ensuite un thread pour la transaction à partir de son pool de threads utilisateur, commence la transaction et transmet les paramètres d’entrée de la méthode à l’environnement d’exécution TI. Ce thread est bloqué pour la transaction jusqu’à ce que la réponse revienne de l’hôte CICS. Il s’agit de l’unité de temps de travail, qui se compose principalement du temps nécessaire à l’application CICS pour traiter la logique métier des transactions et accéder à la base de données en fonction des besoins (en supposant que les vitesses de transmission correspondent à la vitesse du réseau local). Lorsque les paramètres de sortie de la méthode sont renvoyés à .NET à partir de l’hôte, le message de validation est envoyé à DTC.

DTC active la phase de préparation des transactions, ce qui oblige TI à allouer un thread à partir de son pool de threads 2PC et à le maintenir bloqué jusqu’à ce que le message de validation de la demande arrive de l’hôte. Une fois toutes les duplications des transactions préparées, DTC envoie un message de validation complet à .NET, puis renvoie les paramètres de sortie de la méthode et retourne les valeurs à l’application cliente appelante et libère le thread.

Cela termine la transaction pour l’utilisateur, mais les moniteurs de transaction (DTC et CICS) doivent toujours terminer la deuxième phase de la validation, et là encore, un thread du pool de threads TI 2PC est alloué pour chaque transaction effectuant la deuxième phase du commit.

Voir aussi

Programmes transactionnels avec durée d’exécution longue
Intégrateur de transactions - Guide des performances