Implémentation d’un Resource Manager

Chaque ressource utilisée dans une transaction est gérée par un gestionnaire de ressources, dont les actions sont coordonnées par un gestionnaire de transactions. Les gestionnaires de ressources travaillent en collaboration avec le gestionnaire de transactions pour fournir à l’application une garantie d’atomicité et d’isolation. Microsoft SQL Server, files d’attente de messages durables, tables de hachage en mémoire sont tous des exemples de gestionnaires de ressources.

Un gestionnaire de ressources gère les données durables ou volatiles. La durabilité (ou inversement la volatilité) d’un gestionnaire de ressources fait référence à la prise en charge de la récupération des défaillances. Si un gestionnaire de ressources prend en charge la récupération après défaillance, il conserve les données par stockage durable lors de la Phase1 (préparation). Ainsi, s'il connaît une défaillance, il peut à nouveau s'inscrire à la transaction après récupération et procéder aux actions indiquées par les notifications envoyées par le gestionnaire de transactions. En général, les gestionnaires de ressources volatiles gèrent des ressources volatiles telles qu’une structure de données en mémoire (par exemple, une table de hachage transactionnée en mémoire) et les gestionnaires de ressources durables gèrent les ressources qui ont un magasin de stockage plus persistant (par exemple, une base de données dont le magasin de stockage est le disque).

Pour qu’une ressource participe à une transaction, elle doit s’inscrire dans la transaction. La Transaction classe définit un ensemble de méthodes dont les noms commencent par Enlist fournir cette fonctionnalité. Les différentes Enlist méthodes correspondent aux différents types d’inscription qu’un gestionnaire de ressources peut avoir. Plus précisément, vous utilisez les EnlistVolatile méthodes pour les ressources volatiles et la EnlistDurable méthode pour les ressources durables. Par souci de simplicité, après avoir décidé d’utiliser la méthode EnlistDurable ou EnlistVolatile en fonction de la prise en charge de la durabilité de votre ressource, vous devez ajouter votre ressource pour participer à l'engagement en deux phases (2PC) en implémentant l’interface IEnlistmentNotification pour votre gestionnaire de ressources. Pour plus d’informations sur la validation en deux phases, consultez Validation d’une transaction en une seule phase et en plusieurs phases.

En s'inscrivant, le gestionnaire de ressources garantit qu’il obtient des callbacks du gestionnaire de transactions lorsque la transaction est validée ou annulée. On compte une instance de IEnlistmentNotification par inscription. En règle générale, il existe une inscription par transaction, mais un gestionnaire de ressources peut choisir d’inscrire plusieurs fois dans la même transaction.

Après l’inscription, le gestionnaire de ressources répond aux demandes de la transaction. Un gestionnaire de ressources durable stocke suffisamment d’informations pour lui permettre d’annuler ou de rétablir le travail de la transaction sur les ressources qu’elle gère. Il existe de nombreuses façons de le faire ; la conservation des versions des données ou la conservation d’un journal des modifications sont deux techniques courantes.

Lorsque l’application valide la transaction, le gestionnaire de transactions lance le protocole de validation en deux phases. Le gestionnaire de transactions demande d’abord à chaque gestionnaire de ressources inscrit s’il est prêt à valider la transaction. Le gestionnaire de ressources doit se préparer à engager; il se prépare soit à valider, soit à abandonner la transaction.

Pendant la phase de préparation, le gestionnaire de ressources durable enregistre les anciennes et nouvelles données dans un stockage stable afin que le gestionnaire de ressources puisse le récupérer même si le système échoue. Si le gestionnaire de ressources peut se préparer, il informe le gestionnaire de transactions de son vote sur la validation ou l’abandon de la transaction. Si le gestionnaire de ressources signale un échec de préparation, le gestionnaire de transactions envoie une commande de restauration à chaque gestionnaire de ressources et indique l'échec de validation à l'application.

Une fois préparé, un gestionnaire de ressources doit patienter jusqu'à la réception d'un rappel à validation ou d'abandon du gestionnaire de transactions en phase 2. En règle générale, l’ensemble du protocole de préparation et de validation se termine en une fraction de seconde. S’il existe des défaillances système ou de communication, la notification de validation ou d’abandon peut ne pas arriver pendant des minutes ou des heures. Pendant cette période, le gestionnaire de ressources est en doute sur le résultat de la transaction. Il ne sait pas si elle est validée ou abandonnée. Bien que le gestionnaire de ressources soit en doute sur une transaction, il conserve les données modifiées en conservant la transaction verrouillée, isolant ainsi ces modifications des autres transactions.

Lorsqu’un gestionnaire de ressources échoue, toutes ses transactions inscrites sont abandonnées, à l’exception de celles qui sont préparées ou validées avant l’échec. Lorsqu’un gestionnaire de ressources durable redémarre, il reconstruit l’état validé des ressources qu’il gère en récupérant les informations de préparation écrites dans la phase de préparation, et valide ou abandonne ces transactions en conséquence.

En résumé, le protocole de validation en deux phases et les gestionnaires des ressources collaborent pour rendre les transactions atomiques et durables.

La classe Transaction fournit également la méthode EnlistPromotableSinglePhase permettant de s'inscrire à une PSPE (Promotable Single Phase Enlistment). Cela permet à un gestionnaire de ressources durable (RM) d’héberger et de « posséder » une transaction qui peut ultérieurement être réaffectée pour être gérée par le MSDTC si nécessaire. Pour plus d’informations sur ce problème, consultez Optimisation à l’aide de la validation à phase unique et de la notification à phase unique promotable.

Dans cette section

Les étapes généralement suivies par un gestionnaire de ressources sont décrites dans les rubriques suivantes.

Inscription de ressources comme participants à une transaction

Décrit comment une ressource durable ou volatile peut s’inscrire dans une transaction.

Validation d’une transaction en une phase unique et en plusieurs phases

Décrit comment un gestionnaire de ressources répond à la notification de validation et prépare la validation.

Exécution de la récupération

Décrit comment un gestionnaire de ressources durable récupère en cas d’échec.

Niveaux d’approbation de sécurité dans l’accès aux ressources

Décrit comment les trois niveaux d’approbation pour System.Transactions limitent l’accès aux types de ressources qui System.Transactions exposent.

Optimisation à l’aide de la validation à phase unique et de la notification de phase unique pouvant être promue

Décrit les pratiques d’optimisation disponibles pour les implémentations des gestionnaires de ressources.