Compartir a través de

Procesamiento de recuperación

  • Artículo

Después de cualquier tipo de error que interrumpa el procesamiento normal de transacciones, KTM y cada administrador de recursos deben realizar operaciones de recuperación . La recuperación es el proceso por el que los participantes de la transacción llegan a una vista coherente del estado de cada transacción.

Los administradores de recursos pueden estar en duda sobre el resultado de una transacción, lo que significa que en el momento del error, habían recibido una notificación de TRANSACTION_NOTIFY_PREPARE, habían preparado para el almacenamiento duradero, pero no habían recibido (o recibido pero no registrado) un resultado final para la transacción. Del mismo modo, KTM puede dudar sobre una transacción si se había preparado pero no había recibido (o recibido pero no registrado) un resultado. En el momento de la recuperación, todos los resultados que se han enviado, pero que no se han confirmado, deben volver a enviarse. Por ejemplo, si un administrador de recursos recibió una notificación de TRANSACTION_NOTIFY_COMMIT y llamó a la función CommitComplete , rm puede recibir una notificación de TRANSACTION_NOTIFY_COMMIT duplicada en el momento de la recuperación.

Para que una transacción se recupere correctamente después de un error del sistema o del administrador de recursos, cada administrador de recursos debe hacer lo siguiente cada vez que se inicia:

  1. Llame a la función OpenResourceManager para volver a abrir su identificador de Resource Manager mediante su nombre único y persistente. Esto informa a KTM de que el administrador de recursos se está ejecutando de nuevo y está disponible para realizar la recuperación. Si no hay ninguna inscripción para recuperarse, se puede producir un error en la llamada a OpenResourceManager . Llame a CreateResourceManager para volver a crear el objeto RM.

  2. Llame a RecoverResourceManager. El administrador de recursos recibirá un evento de notificación TRANSACTION_NOTIFY_RECOVER para cada inscripción para la que necesita realizar operaciones de recuperación, seguidas de un TRANSACTION_NOTIFY_LAST_RECOVER. El evento de notificación incluye un identificador único global para la transacción y la inscripción.

  3. Llame a la función OpenEnlistment para volver a abrir cada identificador de inscripción para el que el administrador de recursos recibió una notificación de TRANSACTION_NOTIFY_RECOVER.

  4. Para cada inscripción abierta por OpenEnlistment, llame a RecoverEnlistment. Esto hace que la notificación TRANSACTION_NOTIFY_COMMIT o TRANSACTION_NOTIFY_INDOUBT se vuelva a entregar.

  5. Si el RM recibió TRANSACTION_NOTIFY_COMMIT, rm puede completar la transacción llamando a CommitComplete.

    Si el RM recibió TRANSACTION_NOTIFY_INDOUBT, el RM debe esperar a que llegue la notificación de resultado.

  6. En el caso de las transacciones para las que el RM no recibe una notificación de TRANSACTION_NOTIFY_RECOVER, pero anteriormente recibió una notificación de TRANSACTION_NOTIFY_PREPARE, el RM debe procesar la transacción como si se revierte.

Nota:

Los administradores de recursos pueden inscribirse o crear nuevas transacciones durante el proceso de recuperación.

 

KTM usa un modelo de transacción de anulación supuesto . En el escenario siguiente se muestra este comportamiento. Supongamos que KTM y un administrador de recursos existen en el mismo equipo. Supongamos que KTM emite una notificación de preparación para una transacción, pero el sistema se bloquea antes de que KTM registre la notificación de preparación. Supongamos además que el administrador de recursos recibe y registra la notificación de preparación justo antes de que se bloquee el sistema. Una vez restaurado el sistema, KTM no tiene conocimiento de la transacción, ya que nunca registró la fase de preparación. El administrador de recursos tiene conocimiento de la transacción, ya que recibió, procesó y registró la notificación de preparación. Cuando KTM emite sus notificaciones de recuperación, el administrador de recursos no incluye una notificación de recuperación para la transacción en cuestión. Con el modelo de anulación supuesto, el administrador de recursos en este caso tratará la transacción preparada como anulada cuando no reciba notificaciones para realizar la recuperación en esa transacción.