Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite 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éinscrire le participant à la transaction après un échec 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 éligible ultérieurement à la récupération, vous devez appeler la EnlistDurable méthode. En outre, vous devez fournir la EnlistDurable méthode avec un identificateur resource manager (a Guid) utilisé pour étiqueter de manière cohérente le participant de la transaction en cas d’échec de ressource. Pour cette raison, celui Guid fourni à l’appel d’inscription initial doit être identique au paramètre resourceManagerIdentifier dans l’appel pendant la Reenlist récupération. Sinon, TransactionException est levée. Pour plus d’informations sur les inscriptions durables, consultez Enlisting Resources as Participants in a 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 est accessible ultérieurement lors de la récupération en récupérant la RecoveryInformation propriété du rappel prepareEnlistment . La journalisation des enregistrements n’a pas besoin d’être effectuée dans la Prepare méthode, car rm peut le faire sur un thread de travail.
Le processus de récupération se compose des deux étapes suivantes :
Étape 1 - ReEnlist
Le gestionnaire de ressources examine l’enregistrement de préparation des informations pour chaque inscription qui est en doute. Pour ce faire, examinez la RecoveryInformation propriété du rappel, qui est transmise au gestionnaire de ressources dans la notification au cours de PreparingEnlistment la Prepare 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 lorsqu’un Reenlist gestionnaire de ressources redémarre à partir d’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éinscriré à l’aide de cette méthode, les méthodes de phase 2 correspondant au résultat de IEnlistmentNotification la transaction (autrement dit, CommitRollback ou InDoubt ) sont appelées comme appropriées.
É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 nécessaire pour résoudre toutes les transactions sans doute avant de s’inscrire dans 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.