Processamento de recuperação
Após qualquer tipo de falha que interrompa o processamento normal de transações, o KTM e cada gerenciador de recursos devem executar operações de recuperação . A recuperação é o processo pelo qual os participantes da transação chegam a uma exibição consistente do estado de cada transação.
Os gerenciadores de recursos podem estar em dúvida sobre o resultado de uma transação, o que significa que, no momento da falha, eles receberam uma notificação de TRANSACTION_NOTIFY_PREPARE, prepararam-se para o armazenamento durável, mas não receberam (ou receberam, mas não registraram) um resultado final para a transação. Da mesma forma, o KTM pode estar em dúvida sobre uma transação se ela tiver sido preparada, mas não tiver recebido (ou recebido, mas não registrado) um resultado. No momento da recuperação, todos os resultados que foram enviados, mas não confirmados, devem ser reenançados. Por exemplo, se um gerenciador de recursos recebeu uma notificação TRANSACTION_NOTIFY_COMMIT e chamou a função CommitComplete , o RM ainda poderá receber uma notificação de TRANSACTION_NOTIFY_COMMIT duplicada no momento da recuperação.
Para que uma transação seja recuperada corretamente após uma falha do gerenciador de recursos ou do sistema, cada gerenciador de recursos deve fazer o seguinte sempre que for iniciado:
Chame a função OpenResourceManager para reabrir o identificador do gerenciador de recursos usando seu nome exclusivo e persistente. Isso informa à KTM que o gerenciador de recursos está em execução novamente e está disponível para executar a recuperação. Se não houver nenhuma inscrição a ser recuperada, a chamada para OpenResourceManager poderá falhar. Chame CreateResourceManager para recriar o objeto RM.
Chame RecoverResourceManager. O gerenciador de recursos receberá um evento de notificação TRANSACTION_NOTIFY_RECOVER para cada inscrição para o qual ele precisa executar operações de recuperação, seguido por um TRANSACTION_NOTIFY_LAST_RECOVER. O evento de notificação inclui um identificador global exclusivo para a transação e a inscrição.
Chame a função OpenEnlistment para reabrir cada identificador de inscrição para o qual o gerenciador de recursos recebeu uma notificação de TRANSACTION_NOTIFY_RECOVER.
Para cada inscrição aberta pelo OpenEnlistment, chame RecoverEnlistment. Isso faz com que a notificação TRANSACTION_NOTIFY_COMMIT ou TRANSACTION_NOTIFY_INDOUBT seja entregue novamente.
Se o RM recebeu TRANSACTION_NOTIFY_COMMIT, o RM pode concluir a transação chamando CommitComplete.
Se o RM recebeu TRANSACTION_NOTIFY_INDOUBT, o RM deverá aguardar a chegada da notificação de resultado.
Para todas as transações para as quais o RM não recebe uma notificação de TRANSACTION_NOTIFY_RECOVER, mas recebeu anteriormente uma notificação de TRANSACTION_NOTIFY_PREPARE, o RM deve processar a transação como se tivesse sido revertida.
Observação
Os gerenciadores de recursos têm permissão para se inscrever ou criar novas transações durante o processo de execução da recuperação.
KTM usa um modelo de transação de anulação presumida . O cenário a seguir ilustra esse comportamento. Suponha que o KTM e um gerenciador de recursos existam no mesmo computador. Suponha que o KTM emita uma notificação de preparação para uma transação, mas o sistema falha antes que o KTM registre a notificação de preparação. Suponha ainda que o gerenciador de recursos receba e registre a notificação de preparação logo antes da falha do sistema. Depois que o sistema é restaurado, o KTM não tem conhecimento da transação, pois nunca registrou a fase de preparação. O gerenciador de recursos tem conhecimento da transação, pois recebeu, processou e registrou a notificação de preparação. Quando o KTM emite suas notificações de recuperação, o gerenciador de recursos não inclui uma notificação de recuperação para a transação em questão. Com o modelo de anulação presumida, o gerenciador de recursos nesse caso tratará a transação preparada como anulada quando não receber notificações para executar a recuperação nessa transação.