복구 처리
정상적인 트랜잭션 처리를 방해하는 모든 유형의 실패 후 KTM과 각 리소스 관리자는 복구 작업을 수행해야 합니다. 복구는 트랜잭션 참가자가 각 트랜잭션 상태의 일관된 보기에 도달하는 프로세스입니다.
리소스 관리자는 트랜잭션의 결과에 대해 의심 의 여지가 있을 수 있습니다. 즉, 실패 시 TRANSACTION_NOTIFY_PREPARE 알림을 받았고, 지속성 스토리지를 준비했지만 트랜잭션에 대한 최종 결과를 수신(또는 수신했지만 기록되지 않음)하지 않았습니다. 마찬가지로, KTM은 트랜잭션이 준비되었지만 결과를 받지 못했거나 받지 않았거나 기록되지 않은 경우 트랜잭션에 대해 의심할 수 있습니다. 복구 시 전송되었지만 승인되지 않은 모든 결과를 다시 보내야 합니다. 예를 들어 리소스 관리자가 TRANSACTION_NOTIFY_COMMIT 알림을 받고 CommitComplete 함수라고 하는 경우 RM은 복구 시 중복된 TRANSACTION_NOTIFY_COMMIT 알림을 받을 수 있습니다.
리소스 관리자 또는 시스템 오류 후 트랜잭션이 제대로 복구되려면 각 리소스 관리자가 시작될 때마다 다음을 수행해야 합니다.
OpenResourceManager 함수를 호출하여 고유한 영구 이름을 사용하여 리소스 관리자 핸들을 다시 엽니다. 그러면 리소스 관리자가 다시 실행 중이며 복구를 수행할 수 있음을 KTM에 알릴 수 있습니다. 복구할 인리스트먼트가 없으면 OpenResourceManager 호출이 실패할 수 있습니다. CreateResourceManager를 호출하여 RM 개체를 다시 만듭니다.
RecoverResourceManager를 호출합니다. 리소스 관리자는 복구 작업을 수행해야 하는 각 인리스트먼트에 대한 TRANSACTION_NOTIFY_RECOVER 알림 이벤트와 TRANSACTION_NOTIFY_LAST_RECOVER 받습니다. 알림 이벤트에는 트랜잭션과 인리스트먼트 모두에 대한 전역적으로 고유한 식별자가 포함됩니다.
OpenEnlistment 함수를 호출하여 리소스 관리자가 TRANSACTION_NOTIFY_RECOVER 알림을 받은 각 인리스트먼트 핸들을 다시 엽니다.
OpenEnlistment에서 연 각 인리스트먼트에 대해 RecoverEnlistment를 호출합니다. 이로 인해 TRANSACTION_NOTIFY_COMMIT 또는 TRANSACTION_NOTIFY_INDOUBT 알림이 다시 배달됩니다.
RM이 TRANSACTION_NOTIFY_COMMIT 받은 경우 RM은 CommitComplete를 호출하여 트랜잭션을 완료할 수 있습니다.
RM이 TRANSACTION_NOTIFY_INDOUBT 받은 경우 RM은 결과 알림이 도착할 때까지 기다려야 합니다.
RM이 TRANSACTION_NOTIFY_RECOVER 알림을 받지 않지만 이전에 TRANSACTION_NOTIFY_PREPARE 알림을 받은 트랜잭션의 경우 RM은 트랜잭션을 롤백된 것처럼 처리해야 합니다.
참고
리소스 관리자는 복구를 수행하는 동안 새 트랜잭션에 참여하거나 새 트랜잭션을 만들 수 있습니다.
KTM은 추정된 중단 트랜잭션 모델을 사용합니다. 다음 시나리오에서는 이 동작을 보여 줍니다. KTM과 리소스 관리자가 동일한 컴퓨터에 있다고 가정합니다. KTM이 트랜잭션에 대한 준비 알림을 발급하지만 KTM이 준비 알림을 기록하기 전에 시스템이 충돌한다고 가정합니다. 또한 리소스 관리자가 시스템 크래시 직전에 준비 알림을 수신하고 기록한다고 가정합니다. 시스템이 복원된 후 KTM은 준비 단계를 기록하지 않았기 때문에 트랜잭션에 대한 지식이 없습니다. 리소스 관리자는 준비 알림을 수신, 처리 및 기록했기 때문에 트랜잭션에 대한 지식을 가지고 있습니다. KTM이 복구 알림을 발급하는 경우 리소스 관리자는 해당 트랜잭션에 대한 복구 알림을 포함하지 않습니다. 추정된 중단 모델을 사용하면 이 경우 리소스 관리자는 해당 트랜잭션에 대한 복구를 수행하기 위한 알림을 받지 못할 때 준비된 트랜잭션을 중단된 것으로 처리합니다.