Partager via

Prise en charge des transactions et des validations en deux phases

  • Article

Dans com termwinology, une transaction est toujours une unité de travail atomique, cohérente, isolée et durable (ACID). Dans la terminologie mainframe, une transaction peut ou non être une transaction ACID ; Dans la terminologie mainframe, une transaction est un ensemble d’opérations ou de commandes dans un programme de transaction (TP). Cette différence de terminologie peut prêter à confusion. Le mot transaction tel qu’il est utilisé dans TI Manager et TI Designer fait toujours référence à une transaction ACID.

La validation en deux phases (2PC) est un protocole qui permet à un ensemble d’opérations ou de commandes d’application (ou inter-applications) d’être toutes restaurées ou toutes validées en tant qu’unité transactionnelle unique.

Notes

Si vous appelez un serveur TI Automation via le protocole TCP/IP, les transactions de validation en deux phases ne sont pas prises en charge. La validation en deux phases fonctionne uniquement sur le protocole APPC/LU 6.2 SNA.

Un composant TI a quatre propriétés transactionnelles possibles :

  • Nécessite une transaction

  • Nécessite une nouvelle transaction

  • Prend en charge les transactions

  • Ne prend pas en charge les transactions

    Les deux premiers choix nécessitent que le tp mainframe soit transactionnel (c’est-à-dire qu’il respecte les propriétés ACID) et qu’il prend en charge le niveau de synchronisation 2. Cela est transparent pour le tp de mainframe s’il s’agit d’un programme CICS Link ou IMS version 6.0 ou ultérieure. Le troisième choix nécessite que le tp mainframe prend en charge les requêtes de niveau de synchronisation 2 et gère la sémantique de transaction de manière appropriée. Le quatrième choix est requis pour les fournisseurs de services IMS antérieurs à IMS version 6.0 et pour tous les programmes CICS qui prennent uniquement en charge le niveau de synchronisation 0 ou le niveau de synchronisation 1.

    Si un composant TI est appelé dans l’étendue d’une transaction COM+, TI établit une conversation de niveau de synchronisation 2 avec CICS (sinon, le niveau de synchronisation 0 est utilisé). Cela est transparent pour le client du composant TI. Si le tp mainframe est un programme CICS Link, la nature transactionnelle de la conversation est également transparente pour le TP, car la transaction miroir d’IBM dans CICS (CSMI) gère le protocole sync level 2, et le TP auquel elle est liée ignore si le niveau de synchronisation 0 ou sync level 2 est utilisé.

    TI est conforme au modèle de programmation COM+ en appelant SetComplete ou SetAbort quand il termine l’opération de chaque appel de méthode à partir du client. Si aucune erreur n’a été détectée, TI appelle SetComplete ; sinon, il appelle SetAbort. TI appelle également SetAbort si le tp mainframe indique que la transaction ne doit pas être validée en définissant l’indicateur DisableCommit dans le bloc d’erreur de métadonnées retourné. Les applications clientes TI Automation peuvent également choisir d’appeler SetAbort si elles déterminent qu’il existe des problèmes au niveau de l’application qui doivent empêcher la validation de la transaction.

    Lorsque l’appel de méthode du client est retourné, le tp sur le mainframe a effectué une unité de travail, mais les modifications apportées aux ressources protégées dans CICS ne sont pas encore validées. TI utilise de nouvelles interfaces DTC pour inscrire la conversation sync level 2 sur la transaction DTC. Lorsque DTC est prêt à valider ou à abandonner la transaction, il communique avec TI pour piloter les flux de validation en deux phases appropriés sur la conversation LU 6.2. Là encore, tout le travail 2PC est effectué de manière transparente par TI pour le compte du client.

    Bien que l’objet TI puisse être désactivé à la fin de la méthode, la conversation doit être maintenue jusqu’à ce que la transaction soit validée ou abandonnée. Les utilisateurs peuvent nuire aux performances et lier les ressources système si leur code d’application effectue un ou plusieurs appels de méthode transactionnelle, mais ne valide pas la transaction pendant une longue période. Les conversations peuvent être rapidement consommées par un code utilisateur mal structuré.

    Lorsqu’une conversation est en attente de validation, elle est séparée de l’objet auquel elle a été associée. TI gère un pool de ces conversations « en attente » et effectue les opérations de niveau synchronisation requises lorsque les notifications appropriées sont reçues de DTC. Lorsque cela est possible, TI réutilise ces conversations pour réduire la surcharge.

    TI fournit également un service de resynchronisation (SNA LU 6.2 Resync TP). Ce service Windows est configuré pour être le service invokable démarré automatiquement pour le tp resynchronisation défini par SNA (0x06f2). Le service Resync implémente les fonctions « Noms de journaux Exchange » et « Comparer les états » d’un gestionnaire de transactions SNA. Il permet à DTC (Distributed Transaction Coordinator) et CICS d’initier le processus de récupération en fonction des besoins lors du démarrage du système ou suite à un échec de système ou de communication.

    Pour plus d’informations sur les flux SNA SyncPoint ou 2PC d’IBM, consultez Référence de l’architecture SNA SyncPoint Services (IBM SC31-8134-00). Tous les flux TI 2PC sont implémentés conformément à cette architecture.

Notes

Pour plus d’informations sur l’utilisation des TPs de liaison CICS qui utilisent des commandes SYNCPOINT explicites, voir TPs avec des commandes SYNCPOINT explicites.

En résumé, pour utiliser la validation en deux phases, vous devez répondre à toutes les exigences suivantes :

  • Les unités logiques locales et distantes doivent chacune avoir la prise en charge de SyncPoint activée dans le nœud Host Integration Server.

  • Les unités logiques locales et distantes doivent chacune pointer vers l’ordinateur qui exécute les services resynchronisation.

  • La prise en charge de l’environnement distant (RE) doit être activée. Pour case activée cela, cliquez avec le bouton droit sur re dans le gestionnaire TI, cliquez sur Propriétés, puis sur l’onglet LU 6.2.

  • La prise en charge des transactions doit être définie sur Prise en charge des transactions, Obligatoire ou Nouveau requis. Pour case activée ce paramètre, cliquez avec le bouton droit sur le composant TI dans TI Manager, cliquez sur Propriétés, puis cliquez sur l’onglet Transactions.

  • L’ordinateur hôte distant doit être configuré pour la prise en charge de la synchronisation de niveau 2.

Voir aussi

Modèle de programmation WIP