Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Un gestionnaire de ressources facilite la résolution des inscriptions durables dans une transaction en réenrôlant un participant à la transaction après une panne de ressource.
Processus de récupération
Pour inscrire durablement une ressource (décrite par une implémentation de l’interface IEnlistmentNotification) qui peut être admissible ultérieurement à la récupération, vous devez appeler la méthode EnlistDurable. En outre, vous devez fournir la EnlistDurable méthode avec un identificateur de gestionnaire de ressources (un Guid) utilisé pour identifier de manière cohérente le participant de la transaction en cas de panne de ressource. Pour cette raison, le Guid fourni à l’appel d’inscription initial doit être identique au paramètre resourceManagerIdentifier dans l’appel Reenlist pendant la récupération. sous peine de lever une exception TransactionException. Pour plus d’informations sur les inscriptions durables, consultez Inscription de ressources comme participants à une transaction.
Dans la phase de préparation (phase 1) du protocole 2PC, lorsque votre implémentation d’un gestionnaire de ressources durable reçoit la Prepare notification, elle doit consigner son enregistrement de préparation pendant cette phase. L’enregistrement doit contenir toutes les informations nécessaires pour terminer la transaction lors de la validation. L’enregistrement de préparation peut être consulté ultérieurement lors de la récupération en accédant à la propriété RecoveryInformation du rappel preparingEnlistment. La journalisation des enregistrements n’a pas besoin d’être effectuée dans la Prepare méthode, car le RM peut le faire sur un thread de travail.
Le processus de récupération se compose des deux étapes suivantes :
Étape 1 - Réenrôler
Le gestionnaire de ressources examine l'enregistrement d'informations de préparation de chaque inscription incertaine. Pour ce faire, examinez la propriété RecoveryInformation du rappel PreparingEnlistment, qui est transmise au gestionnaire de ressources dans la notification Prepare au cours de la phase 1.
Pour chaque inscription qu’elle examine, elle appelle Reenlist sur le gestionnaire de transactions. Cette méthode transmet un élément unique Guid qui identifie le gestionnaire de ressources, ainsi que les informations de l’inscription dans un tableau d’octets. Un nouvel Enlistment objet est retourné. Si la réenlistation échoue avec une exception, le gestionnaire de ressources doit réessayer ultérieurement.
Vous devez uniquement appeler la méthode Reenlist lorsqu’un gestionnaire de ressources redémarre après une défaillance. En outre, vous ne devez réinscrire que les transactions non résolues enregistrées par un gestionnaire de ressources pendant la phase de préparation initiale d’une validation en deux phases. Toute tentative d’appel de cette méthode à des moments non valides peut produire des résultats erronés.
Lorsqu’un participant est réinscrit à l’aide de cette méthode, les méthodes de phase 2 correspondant au résultat de la transaction IEnlistmentNotification (autrement dit, Commit, Rollback ou InDoubt) sont appelées en conséquence.
Étape 2 : fin de la récupération
Lorsque toutes les réenlistments sont terminées, le gestionnaire de ressources appelle la RecoveryComplete méthode. Cette méthode termine la récupération et informe le gestionnaire de transactions que le gestionnaire de ressources n’a plus de transactions en doute. Ainsi, le gestionnaire de ressources garantit qu’il n’appellera pas à nouveau la Reenlist méthode.
Un gestionnaire de ressources n'est pas obligé de résoudre toutes les transactions en suspens avant de participer à de nouvelles transactions. La première étape peut être effectuée à tout moment après que le gestionnaire de ressources établit une relation avec le gestionnaire de transactions, mais après RecoveryComplete avoir été appelée (étape 2) ; l’étape 1 ne peut pas être rééditée. L’étape 2 peut être répétée plusieurs fois sans affecter le résultat des transactions.