Partager via


Traitement de la récupération

Après tout type de défaillance qui interrompt le traitement normal des transactions, KTM et chaque gestionnaire de ressources doivent effectuer des opérations de récupération . La récupération est le processus par lequel les participants à la transaction parviennent à une vue cohérente de l’état de chaque transaction.

Les gestionnaires de ressources peuvent douter du résultat d’une transaction, ce qui signifie qu’au moment de l’échec, ils avaient reçu une notification TRANSACTION_NOTIFY_PREPARE, s’étaient préparés à un stockage durable, mais n’avaient pas reçu (ou reçu, mais pas enregistré) un résultat final pour la transaction. De même, KTM peut douter d’une transaction si elle avait été préparée, mais qu’elle n’avait pas reçu (ou reçu, mais pas journalisé) un résultat. Au moment de la récupération, tous les résultats qui ont été envoyés mais non reconnus doivent être renvoyés. Par exemple, si un gestionnaire de ressources a reçu une notification TRANSACTION_NOTIFY_COMMIT et appelé la fonction CommitComplete , le gestionnaire de ressources peut toujours recevoir une notification TRANSACTION_NOTIFY_COMMIT en double au moment de la récupération.

Pour qu’une transaction soit correctement récupérée après une défaillance du système ou d’un gestionnaire de ressources, chaque gestionnaire de ressources doit effectuer les opérations suivantes chaque fois qu’elle est démarrée :

  1. Appelez la fonction OpenResourceManager pour rouvrir son handle resource manager à l’aide de son nom unique et persistant. Cela informe KTM que le gestionnaire de ressources s’exécute à nouveau et qu’il est disponible pour effectuer la récupération. S’il n’existe aucune inscription à récupérer, l’appel à OpenResourceManager peut échouer. Appelez CreateResourceManager pour recréer l’objet RM.

  2. Appelez RecoverResourceManager. Le gestionnaire de ressources reçoit un événement de notification TRANSACTION_NOTIFY_RECOVER pour chaque inscription pour laquelle il doit effectuer des opérations de récupération, suivi d’un TRANSACTION_NOTIFY_LAST_RECOVER. L’événement de notification inclut un identificateur global unique pour la transaction et l’inscription.

  3. Appelez la fonction OpenEnlistment pour rouvrir chaque handle d’inscription pour lequel le gestionnaire de ressources a reçu une notification TRANSACTION_NOTIFY_RECOVER.

  4. Pour chaque inscription ouverte par OpenEnlistment, appelez RecoverEnlistment. La notification TRANSACTION_NOTIFY_COMMIT ou TRANSACTION_NOTIFY_INDOUBT est alors redélivée.

  5. Si le RM a reçu TRANSACTION_NOTIFY_COMMIT, le RM peut terminer la transaction en appelant CommitComplete.

    Si le RM a reçu TRANSACTION_NOTIFY_INDOUBT, il doit attendre l’arrivée de la notification de résultat.

  6. Pour toutes les transactions pour lesquelles le RM ne reçoit pas de notification TRANSACTION_NOTIFY_RECOVER, mais pour lesquelles il a reçu une notification de TRANSACTION_NOTIFY_PREPARE, le RM doit traiter la transaction comme si elle avait été restaurée.

Notes

Les gestionnaires de ressources sont autorisés à s’inscrire ou à créer de nouvelles transactions pendant le processus de récupération.

 

KTM utilise un modèle de transaction d’abandon présumé . Le scénario suivant illustre ce comportement. Supposons que KTM et un gestionnaire de ressources existent sur le même ordinateur. Supposons que KTM émet une notification de préparation pour une transaction, mais que le système se bloque avant que KTM consigne la notification de préparation. En outre, supposons que le gestionnaire de ressources reçoit et consigne la notification de préparation juste avant le blocage du système. Une fois le système restauré, KTM n’a aucune connaissance de la transaction, car il n’a jamais enregistré la phase de préparation. Le gestionnaire de ressources a connaissance de la transaction, car il a reçu, traité et consigné la notification de préparation. Lorsque KTM émet ses notifications de récupération, le gestionnaire de ressources n’inclut pas de notification de récupération pour la transaction en question. Avec le modèle présumé d’abandon, le gestionnaire de ressources dans ce cas traite la transaction préparée comme abandonnée lorsqu’il ne reçoit pas de notifications pour effectuer la récupération de cette transaction.