Création d’un Resource Manager
Les gestionnaires de ressources gèrent les données de chaque transaction et journalisent les opérations de la transaction. Si un système de traitement des transactions (TPS) a plusieurs gestionnaires de ressources, chaque gestionnaire de ressources peut participer aux opérations de validation, de restauration et de récupération de chaque transaction.
Chaque gestionnaire de ressources doit exporter une interface que les clients transactionnels peuvent utiliser pour accéder à la base de données ou à une autre ressource qu’il gère.
En règle générale, un gestionnaire de ressources en mode noyau doit effectuer les tâches suivantes dans l’ordre indiqué :
Créez un flux de journal.
Les gestionnaires de ressources peuvent utiliser le système CLFS (Common Log File System ) ou une autre fonctionnalité de journalisation pour gérer leurs flux de journaux. Un appel à ClfsCreateLogFile crée un flux de journal CLFS. Le gestionnaire de ressources doit utiliser le flux de journal pour enregistrer toutes les informations dont il a besoin pour valider, restaurer ou récupérer des transactions. En outre, KTM utilise le flux de journaux pour enregistrer les modifications d’état internes qui peuvent être nécessaires pour récupérer des transactions.
Créez un objet de gestionnaire de transactions.
Un appel à ZwCreateTransactionManager crée un objet de gestionnaire de transactions et connecte le gestionnaire de ressources à un flux de journal CLFS supplémentaire spécifié par le gestionnaire de ressources.
Récupérez l’état du gestionnaire de transactions.
Un appel à ZwRecoverTransactionManager lit le flux de journal de l’objet gestionnaire de transactions (que KTM gère) et détermine si le TPS a été arrêté avant que toutes les transactions soient terminées (par exemple, en raison d’un blocage du système). KTM restaure son état interne en fonction des informations contenues dans le flux de journal.
Créez un objet Resource Manager.
Un appel à ZwCreateResourceManager crée un objet resource manager et l’associe à l’objet gestionnaire de transactions créé précédemment.
Récupérez l’état du gestionnaire de ressources.
Un appel à ZwRecoverResourceManager amène KTM à envoyer au gestionnaire de ressources TRANSACTION_NOTIFY_RECOVER des notifications pour toutes les transactions qui étaient en cours la dernière fois que le gestionnaire de ressources s’est arrêté. Pour plus d’informations sur la façon dont le gestionnaire de ressources doit répondre à ces notifications, consultez Gestion des opérations de récupération.
Recevoir des transactions de clients.
En règle générale, un client crée un objet de transaction et utilise l’interface cliente du gestionnaire de ressources pour passer le GUID de l’objet de transaction au gestionnaire de ressources. Par exemple, le gestionnaire de ressources peut fournir une routine CreateDataObject similaire à celle décrite dans la rubrique Présentation des composants TPS .
Inscrivez-vous à chaque transaction.
Un appel à ZwOpenTransaction ouvre un handle à l’objet transaction, puis un appel à ZwCreateEnlistment crée un enrôlement pour la transaction. L’inscription permet au gestionnaire de ressources de recevoir un ensemble spécifié de notifications de transaction.
Activer la réception des notifications de transaction.
Le gestionnaire de ressources peut appeler ZwGetNotificationResourceManager pour obtenir des notifications de manière synchrone, ou il peut appeler TmEnableCallbacks pour inscrire une routine de rappel ResourceManagerNotification que KTM appelle chaque fois qu’une notification est disponible.
Les demandes d’accès aux ressources de service des clients, mais ne rendent pas les modifications permanentes.
Une fois qu’un client a créé un objet de transaction, il appelle généralement l’interface du gestionnaire de ressources pour accéder à la ressource du gestionnaire de ressources. Par exemple, un gestionnaire de ressources pour une base de données peut recevoir des demandes de lecture et d’écriture dans la base de données.
Le gestionnaire de ressources doit enregistrer les résultats des opérations de lecture et d’écriture dans un flux de journaux CLFS ou une autre fonctionnalité de journalisation jusqu’à ce qu’il reçoive une notification indiquant que les opérations de la transaction seront validées, restaurées ou récupérées.
Valider ou restaurer les opérations du client.
Finalement, le gestionnaire de ressources reçoit une notification pour commencer à valider ou à restaurer les opérations effectuées par le client. En réponse, le gestionnaire de ressources doit rendre les opérations clientes permanentes ou les ignorer. Pour plus d’informations sur la gestion des notifications de validation et de restauration, consultez Gestion des opérations de transaction.
Parfois, un gestionnaire de ressources peut avoir à essayer de forcer KTM à fournir rapidement une notification de validation ou de restauration, peut-être parce que le gestionnaire de ressources a déterminé qu’un appareil a été supprimé par surprise. Dans ce cas, le gestionnaire de ressources peut appeler TmRequestOutcomeEnlistment.
Fermez le handle de l’objet d’inscription.
Une fois que le gestionnaire de ressources a terminé de traiter la transaction, il doit appeler ZwClose pour fermer le handle de l’objet d’inscription
Fermez le handle d’objet resource manager et le handle d’objet du gestionnaire de transactions.
Avant le déchargement du gestionnaire de ressources, il doit appeler ZwClose pour fermer le handle de l’objet resource manager et le handle de l’objet gestionnaire de transactions.
Les étapes 1 à 5 doivent être effectuées dans le code d’initialisation de votre gestionnaire de ressources. Par exemple, si votre gestionnaire de ressources est un pilote en mode noyau, le code d’initialisation est la routine DriverEntry du pilote.
Les étapes 6 à 11 sont généralement effectuées dans du code qui répond aux demandes des clients transactionnels.
L’étape 12 doit être effectuée dans le code de propre final de votre gestionnaire de ressources, comme la routine de déchargement d’un pilote en mode noyau.
Création d’une inscription Read-Only
Une inscription en lecture seule est une inscription qui ne reçoit aucune notification de la part de KTM. Un gestionnaire de ressources peut rendre toute inscription en lecture seule en appelant ZwReadOnlyEnlistment. Cet appel entraîne l’arrêt de la remise de notifications par KTM au gestionnaire de ressources.
Une fois que votre gestionnaire de ressources a appelé ZwCreateEnlistment, il peut appeler ZwReadOnlyEnlistment à tout moment jusqu’au moment où il appelle généralement ZwPrepareComplete.
Vous pouvez souhaiter que votre gestionnaire de ressources appelle ZwReadOnlyEnlistment pour deux raisons.
Votre gestionnaire de ressources a participé à une transaction et, à un moment donné, avant de recevoir une notification TRANSACTION_NOTIFY_COMMIT, le gestionnaire de ressources détermine qu’il n’a plus à participer à l’opération de validation de la transaction.
Par exemple, lorsque le gestionnaire de ressources reçoit une notification TRANSACTION_NOTIFY_PREPARE, il peut déterminer qu’aucune des opérations de la transaction n’a changé la base de données du gestionnaire de ressources. Le gestionnaire de ressources peut appeler ZwReadOnlyEnlistment au lieu de ZwPrepareComplete pour se supprimer de la transaction.
Votre gestionnaire de ressources ne participe jamais à l’opération de validation d’une transaction.
Par exemple, votre gestionnaire de ressources peut surveiller les données que le client envoie, sans modifier la base de données stockée. Dans ce cas, votre gestionnaire de ressources peut appeler ZwReadOnlyEnlistment immédiatement après avoir appelé ZwCreateEnlistment. En outre, vous pouvez choisir de rendre ce gestionnaire de ressources volatile, comme décrit dans la section suivante de cette rubrique.
Une fois qu’un gestionnaire de ressources a appelé ZwReadOnlyEnlistment, il peut appeler ZwClose pour fermer le handle d’inscription.
Création d’un Volatile-Resource Manager
Un gestionnaire de ressources volatiles est un gestionnaire de ressources qui ne gère pas les données durables. Par exemple, vous pouvez créer un gestionnaire de ressources volatiles pour surveiller les données que le client envoie, si le gestionnaire de ressources ne modifie pas une base de données stockée durablement. Les gestionnaires de ressources volatiles n’enregistrent généralement pas l’activité des transactions et ne peuvent donc pas effectuer d’opérations de récupération ou de restauration.
Un gestionnaire de ressources volatiles doit définir l’indicateur RESOURCE_MANAGER_VOLATILE lorsqu’il appelle ZwCreateResourceManager. Si cet indicateur est défini, KTM n’enregistre aucune information sur le gestionnaire de ressources dans le flux de journaux de l’objet gestionnaire de transactions associé.
Votre gestionnaire de ressources peut également définir un indicateur TRANSACTION_MANAGER_VOLATILE lorsqu’il appelle ZwCreateTransactionManager. Si cet indicateur est défini, KTM ne crée pas de flux de journal pour l’objet gestionnaire de transactions. En outre, tous les gestionnaires de ressources supplémentaires connectés à l’objet gestionnaire de transactions doivent également être volatiles et définir l’indicateur RESOURCE_MANAGER_VOLATILE.
Ajout d’un Resource Manager à un TPS existant
Si vous devez ajouter un gestionnaire de ressources supplémentaire à un TPS existant, vous avez deux possibilités :
Votre nouveau gestionnaire de ressources appelle ZwCreateTransactionManager pour créer son propre objet de gestionnaire de transactions.
Utilisez ce choix si votre gestionnaire de ressources ne communique pas avec d’autres gestionnaires de ressources dans le TPS.
Votre nouveau gestionnaire de ressources appelle ZwOpenTransactionManager pour se connecter à un objet de gestionnaire de transactions existant.
Utilisez ce choix si votre gestionnaire de ressources doit communiquer avec d’autres gestionnaires de ressources dans le TPS. Le gestionnaire de ressources qui appelle ZwCreateTransactionManager doit partager le GUID de l’objet de gestionnaire de transactions, le nom du flux de journal ou le nom de l’objet afin que d’autres gestionnaires de ressources puissent appeler ZwOpenTransactionManager. Ces autres gestionnaires de ressources peuvent appeler ZwQueryInformationTransactionManager pour obtenir des informations supplémentaires sur l’objet gestionnaire de transactions.
Une fois que vous avez ajouté votre gestionnaire de ressources au TPS, les clients qui connaissent votre gestionnaire de ressources peuvent appeler l’interface cliente du gestionnaire de ressources.