Процесс восстановления

После любого типа сбоя, который нарушает обычную обработку транзакций, KTM и каждый диспетчер ресурсов должны выполнять операции восстановления. Восстановление — это процесс, с помощью которого участники транзакции приходят к согласованному представлению состояния каждой транзакции.

Диспетчеры ресурсов могут находиться в состоянии неопределенности относительно результатов транзакции, что означает, что во время сбоя они получили уведомление TRANSACTION_NOTIFY_PREPARE, подготовили данные для устойчивого хранения, но не получили (или получили, но не зарегистрировали) окончательный результат транзакции. Аналогичным образом, KTM может сомневаться в транзакции, если она была подготовлена, но не получила (или получила, но не зарегистрировала) результат. Во время восстановления все результаты, которые были отправлены, но не подтверждены, должны быть повторно отправлены. Например, если диспетчер ресурсов получил уведомление TRANSACTION_NOTIFY_COMMIT и вызвал функцию CommitComplete, RM может по-прежнему получать повторяющееся уведомление TRANSACTION_NOTIFY_COMMIT во время восстановления.

Для правильного восстановления транзакции после сбоя диспетчера ресурсов или системы каждый диспетчер ресурсов должен выполнять следующие действия при каждом запуске:

1. Вызовите функцию OpenResourceManager, чтобы повторно открыть дескриптор диспетчера ресурсов с помощью постоянного уникального имени. Это сообщает KTM, что диспетчер ресурсов работает снова и доступен для восстановления. Если для восстановления не существуют списки, вызов OpenResourceManager может завершиться ошибкой. Вызовите CreateResourceManager для повторного создания объекта RM.

2. Выполнить вызов RecoverResourceManager. Диспетчер ресурсов получит событие уведомления TRANSACTION_NOTIFY_RECOVER для каждого перечисления, для которого требуется выполнить операции восстановления, а затем TRANSACTION_NOTIFY_LAST_RECOVER. Событие уведомления содержит глобальный уникальный идентификатор как для транзакции, так и для участия.

3. Вызовите функцию OpenEnlistment, чтобы открыть заново каждый дескриптор участия, для которого диспетчер ресурсов получил уведомление TRANSACTION_NOTIFY_RECOVER.

4. Для каждого вхождения, открытого с помощью OpenEnlistment, вызовите RecoverEnlistment. Это вызывает повторную отправку уведомления TRANSACTION_NOTIFY_COMMIT или TRANSACTION_NOTIFY_INDOUBT.

5. Если RM получил TRANSACTION_NOTIFY_COMMIT, RM может завершить транзакцию, вызвав CommitComplete.

   Если RM получила TRANSACTION_NOTIFY_INDOUBT, RM должна подождать получения уведомления о результате.

6. Для любых транзакций, для которых RM не получил уведомление TRANSACTION_NOTIFY_RECOVER, но ранее получило уведомление TRANSACTION_NOTIFY_PREPARE, RM должен обработать транзакцию, как если бы она была отменена.

Заметка

Менеджеры ресурсов имеют право участвовать в существующих или создавать новые транзакции во время процесса восстановления.

 

KTM использует предполагаемую прерывание модели транзакций. Следующий сценарий иллюстрирует это поведение. Предположим, что KTM и диспетчер ресурсов существуют на одном компьютере. Предположим, что KTM выдает уведомление о подготовке транзакции, но система завершает работу до того, как KTM регистрирует уведомление о подготовке. Кроме того, предположим, что диспетчер ресурсов получает и регистрирует уведомление о подготовке непосредственно перед сбоем системы. После восстановления системы KTM не имеет знаний о транзакции, так как она никогда не регистрировала этап подготовки. Диспетчер ресурсов знает о транзакции, так как она получила, обработала и зарегистрировала уведомление о подготовке. Когда KTM выдает уведомления о восстановлении, диспетчер ресурсов не включает уведомление о восстановлении для этой транзакции. При предполагаемой модели прерывания диспетчер ресурсов в этом случае будет рассматривать подготовленную транзакцию как прерванную, если она не получает уведомления о восстановлении для этой транзакции.