Gestion des opérations de validation
Il existe deux types d’opérations de validation : la validation monophase et la validation multiphase. Une opération de validation monophase se compose d’une notification unique à laquelle les gestionnaires de ressources doivent répondre, tandis qu’une opération de validation multiphase inclut des notifications supplémentaires pour les étapes de préparation.
Une opération de validation monophase est plus simple à implémenter. Il convient aux systèmes de traitement des transactions (TPS) qui présentent l’une des caractéristiques suivantes :
Un gestionnaire de ressources unique.
Plusieurs gestionnaires de ressources, dont tous sauf un sont en lecture seule et ne participent pas à l’opération de validation.
Une opération de validation en plusieurs phases est nécessaire si plusieurs gestionnaires de ressources participent à l’opération de validation.
opérations de validation Single-Phase
Si vous souhaitez que votre TPS prend en charge les opérations de validation monophases, un (et un seul) gestionnaire de ressources doit s’inscrire pour recevoir TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT notifications pour ses inscriptions. Tous les autres gestionnaires de ressources doivent être en lecture seule.
Un TPS qui inclut un gestionnaire de transactions supérieur ne peut pas utiliser la validation monophase.
Si un gestionnaire de ressources s’est inscrit pour recevoir TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT notifications, KTM envoie ce type de notification lorsqu’un client transactionnel appelle ZwCommitTransaction.
Lorsque le gestionnaire de ressources reçoit une notification TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT pour une transaction, il peut valider la transaction ou rejeter la validation monophase.
Pour valider la transaction, le gestionnaire de ressources doit effectuer les opérations suivantes :
Videz toutes les données qu’il contient dans un cache non permanent (stockage en mémoire), comme la zone de marshaling CLFS pour un flux de journal CLFS.
Le gestionnaire de ressources doit déplacer les données du cache vers un support de stockage durable. Par exemple, un gestionnaire de ressources qui utilise CLFS peut appeler ClfsFlushBuffers.
Rendre toutes les modifications de données permanentes et publiques (c’est-à-dire visibles en dehors de l’étendue du gestionnaire de ressources).
Appelez ZwCommitComplete.
Après avoir appelé ZwCommitComplete, le gestionnaire de ressources doit appeler ZwClose pour fermer le handle d’inscription.
Pour rejeter une opération de validation monophase pour la transaction, le gestionnaire de ressources peut appeler ZwSinglePhaseReject. Si le gestionnaire de ressources appelle ZwSinglePhaseReject, KTM change immédiatement l’opération de validation de monophase à multiphase.
Si d’autres gestionnaires de ressources s’inscrivent dans la même transaction, ils doivent être en lecture seule. Toutefois, ils doivent s’inscrire pour recevoir la notification TRANSACTION_NOTIFY_RM_DISCONNECTED, qu’ils reçoivent si le gestionnaire de ressources qui gère l’opération de validation en phase unique ferme le handle d’inscription sans indiquer qu’il a validée ou restaurée la transaction.
Opérations de validation multiphases
Une opération de validation en plusieurs phases commence quand l’un des événements suivants se produit :
Un client transactionnel appelle ZwCommitTransaction et aucun gestionnaire de ressources ne s’est inscrit pour recevoir TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT notifications.
Un gestionnaire de ressources appelle ZwSinglePhaseReject après avoir reçu une notification TRANSACTION_NOTIFY_SINGLE_PHASE_COMMIT.
Un gestionnaire de transactions supérieur appelle ZwPrePrepareEnlistment.
Les opérations de validation multiphases se composent de trois phases séquentielles : pré-préparation, préparation et validation.
Phase de pré-préparation
La phase de pré-préparation (également appelée phase zéro) de l’opération de validation commence lorsque KTM envoie une notification TRANSACTION_NOTIFY_PREPREPARE à tous les gestionnaires de ressources. KTM envoie cette notification si aucun gestionnaire de ressources ne prend en charge une opération de validation en une seule phase pour la transaction, ou si un gestionnaire de transactions supérieur appelle ZwPrePrepareEnlistment.
Lorsque chaque gestionnaire de ressources reçoit la notification TRANSACTION_NOTIFY_PREPREPARE, il doit effectuer les opérations suivantes :
Videz toutes les données qu’il contient dans un cache non permanent (stockage en mémoire), comme la zone de marshaling CLFS pour un flux de journal CLFS.
Le gestionnaire de ressources doit déplacer les données du cache vers un support de stockage durable. Par exemple, un gestionnaire de ressources qui utilise CLFS peut appeler ClfsFlushBuffers.
Appelez ZwPrePrepareComplete.
Une fois qu’un gestionnaire de ressources a appelé ZwPreprepareComplete, il peut continuer à recevoir et à traiter les demandes des clients. Toutefois, le gestionnaire de ressources doit traiter toutes les modifications de données comme des opérations directes de cache qui sont immédiatement écrites sur un support de stockage durable.
Si un gestionnaire de ressources rencontre une erreur lors du traitement d’une notification TRANSACTION_NOTIFY_PREPREPARE, il doit appeler ZwRollbackEnlistment pour restaurer la transaction.
Phase de préparation
La phase de préparation (également appelée phase 1) de l’opération de validation commence lorsque KTM envoie une notification TRANSACTION_NOTIFY_PREPARE à tous les gestionnaires de ressources. KTM envoie cette notification après TRANSACTION_NOTIFY_PREPREPARE si aucun gestionnaire de ressources ne prend en charge la validation monophase ou si un gestionnaire de transactions supérieur appelle ZwPrepareEnlistment.
Lorsque chaque gestionnaire de ressources reçoit la notification TRANSACTION_NOTIFY_PREPARE, il doit effectuer les opérations suivantes :
Arrêtez les demandes clientes de maintenance et signalez les requêtes suivantes du client comme des erreurs clientes.
Assurez-vous que toutes les données ont été déplacées vers un stockage durable.
Appelez ZwPrepareComplete.
Si un gestionnaire de ressources rencontre une erreur lors du traitement d’une notification de TRANSACTION_NOTIFY_PREPARE, il doit appeler ZwRollbackEnlistment pour restaurer la transaction. Toutefois, le gestionnaire de ressources ne peut pas restaurer la transaction après avoir appelé ZwPrepareComplete.
Phase de validation
La phase de validation (également appelée phase 2) de l’opération de validation commence lorsque KTM envoie une notification TRANSACTION_NOTIFY_COMMIT à tous les gestionnaires de ressources. KTM envoie cette notification après TRANSACTION_NOTIFY_PREPARE si aucun gestionnaire de ressources ne prend en charge la validation monophase ou si un gestionnaire de transactions supérieur appelle ZwCommitEnlistment.
Lorsque chaque gestionnaire de ressources reçoit la notification TRANSACTION_NOTIFY_COMMIT, il doit effectuer les opérations suivantes :
Rendre toutes les modifications de données permanentes et publiques (c’est-à-dire, visibles pour d’autres transactions).
En règle générale, un gestionnaire de ressources rend les modifications permanentes et publiques en copiant les données enregistrées de la transaction à partir du flux de journaux vers le stockage public et permanent de la base de données. Pour plus d’informations sur l’utilisation des flux de journaux, consultez Utilisation de flux de journaux avec KTM.
Appelez ZwCommitComplete.
Une fois que le gestionnaire de ressources a appelé ZwCommitComplete, il doit appeler ZwClose pour fermer le handle d’inscription.
Si un gestionnaire de ressources rencontre une erreur lors du traitement d’une notification TRANSACTION_NOTIFY_COMMIT, il doit s’arrêter lui-même. La prochaine fois que le système d’exploitation recharge le gestionnaire de ressources, le processus de récupération du gestionnaire de ressources doit restaurer la transaction à un état connu pour être correct avant que l’erreur ne se produise.