Considérations sur les performances de la validation en deux phases
Lorsqu’un composant d’intégrateur de transactions (TI) s’exécute dans une transaction, l’environnement d’exécution TI envoie un message à Microsoft Distributed Transaction Coordinator (DTC) dans l’environnement COM+, en s’inscrivant sur la transaction en tant que type spécial de gestionnaire de ressources LU 6.2. Une fois que TI a envoyé sa mémoire tampon de données à l’hôte et a reçu la réponse, elle appelle la méthode et retourne le SetComplete
contrôle à COM+. À ce stade, l’application cliente ou un autre composant qui pilote l’ti peut effectuer d’autres tâches également incluses dans la même transaction. Lorsque tous les gestionnaires de ressources ont effectué leurs mises à jour et émis SetComplete
, le créateur de la transaction (qui peut être COM+ lui-même pour une transaction automatique) envoie la Commit
méthode à DTC. DTC envoie le message de première phase (Prepare
) à tous les gestionnaires de ressources, y compris l’environnement d’exécution TI. TI génère le Prepare PS Header
défini dans les formats SNA et l’envoie à l’hôte. Il reçoit une RequestCommit
réponse, qui indique que les mises à jour de l’hôte sont valides et peuvent être validées, et transmet ces informations à DTC. DTC collecte les votes de tous les gestionnaires de ressources et, si tous les éléments préparés sont corrects, il force l’écriture d’un enregistrement de validation dans le journal et envoie le Committed
message. Là encore, TI traduit cela en , SNA PS Header
reçoit la réponse et le traduit en DTC. Si tout fonctionne comme prévu, DTC annule la transaction et la conversation APPC/LU 6.2 est libérée.
Notes
Ni TI ni l’AP n’ont besoin de se préoccuper d’un verbe SYNCPT APPC ou CPI/C. La décision de « prendre un SyncPoint » est prise par le créateur de la transaction, est exprimée dans la sémantique des transactions OLE et implique tous les participants à la transaction, pas seulement les branches TI LU 6.2. Le rôle de ti est à un niveau inférieur ; TI agit en tant que gestionnaire de ressources pour DTC. Il se traduit entre les interfaces COM utilisées par DTC et les protocoles SNA compris par l’hôte, pour effectuer les deux phases du protocole et permettre à DTC de prendre la décision commit entre la phase 1 et la phase 2.
Du point de vue des performances, la garantie de l’atomicité des mises à jour de l’hôte ajoute une surcharge importante et inévitable. Il existe deux flux de messages aller-retour supplémentaires vers l’hôte pour la validation en deux phases (2PC), plus les flux de messages Windows à inscrire, et la journalisation des transactions (écritures sur disque forcées) par DTC et sur l’hôte. Les transactions qui ne nécessitent pas beaucoup de traitement de la logique métier peuvent prendre deux fois plus de temps, voire plus, si vous la comparez à la même transaction sans 2PC.
La seule fois où vous devez configurer un composant TI pour prendre en charge les transactions ACID, c’est lorsque le programme de transaction hôte (TP) associé modifie une ressource stratégique qui doit rester cohérente avec les ressources du système d’exploitation Windows. Si le TP ne modifie aucune ressource pour laquelle la cohérence doit être garantie, configurez le composant TI comme Ne prend pas en charge les transactions, afin que 2PC ne soit pas tenté. Ensuite, vous êtes également libre d’utiliser le protocole TCP/IP. Le protocole TCP/IP ne prend pas en charge 2PC.
Les composants TI ne doivent jamais être configurés comme Nécessite une nouvelle transaction. Cela signifie que vous gérez la transaction à distance pour l’hôte, ce qui entraînerait la surcharge liée à la création d’une nouvelle transaction, à l’inscription sur celle-ci et à l’exécution des échanges 2PC avec l’hôte, mais la méthode TI serait une transaction en soi. Il est plus efficace de permettre à CICS et IMS de gérer leurs propres transactions. Les mises à jour sur le système d’exploitation Windows ne font pas partie de cette transaction. Elles sont donc validées ou rétablies indépendamment.
Notes
Un traitement de logique métier supplémentaire sur le même serveur réduit les limites de débit, ce qui vole une partie du processeur. Toutefois, le coût peut être relativement faible dans l’étendue du budget global de temps de réponse.