다음을 통해 공유


복구 수행

리소스 관리자는 리소스 실패 후 트랜잭션 참가자를 재등록하여 트랜잭션의 내구성 있는 등록 문제를 해결하는 데 도움을 줍니다.

복구 프로세스

나중에 복구에 적합할 수 있는 리소스(인터페이스 구현 IEnlistmentNotification 에 설명됨)를 지속적으로 등록하려면 메서드를 EnlistDurable 호출해야 합니다. 또한 리소스 오류가 발생할 경우 트랜잭션 참가자에게 일관되게 레이블을 지정하는 데 사용되는 리소스 관리자 식별자(aEnlistDurable)를 메서드에 제공해야 Guid 합니다. 이러한 이유로 Guid 초기 등록 호출에 제공되는 항목은 복구 시 호출에서의 resourceManagerIdentifier 매개변수와 동일해야 합니다. 그렇지 않으면 TransactionException throw됩니다. 지속성 인리스트먼트에 대한 자세한 내용은 리소스를 트랜잭션의 참가자로 등록을 참조하세요.

2PC 프로토콜의 준비 단계(1단계)에서 사용자의 지속성 리소스 관리자 구현이 Prepare 알림을 받으면, 이 단계에서 준비 기록을 로그해야 합니다. 레코드에는 커밋할 때 트랜잭션을 완료하는 데 필요한 모든 정보가 포함되어야 합니다. RecoveryInformation 콜백의 속성을 검색하여, 나중에 복구 중에 준비 레코드에 액세스할 수 있습니다. RM이 작업자 스레드에서 이 작업을 수행할 수 있으므로 메서드 내에서 Prepare 레코드 로깅을 수행할 필요가 없습니다.

복구 프로세스는 다음 두 단계로 구성됩니다.

1단계 - 다시 등록

리소스 관리자는 의심스러운 각 인리스트먼트에 대한 준비 정보 레코드를 검사합니다. 이 작업은 1단계 동안 RecoveryInformation 알림에서 리소스 관리자에게 전달되는 PreparingEnlistment 콜백의 Prepare 속성을 검사하여 수행됩니다.

검사하는 각 인리스트먼트에 대해 트랜잭션 관리자에서 호출합니다 Reenlist . 이 메서드는 리소스 관리자와 바이트 배열의 인리스트먼트 정보를 식별하는 고유 Guid 정보를 전달합니다. 새 Enlistment 개체가 반환됩니다. 예외로 인해 재참가가 실패한 경우, 리소스 관리자는 나중에 다시 시도해야 합니다.

리소스 관리자가 오류로 인해 재시작할 때에만 Reenlist 메서드를 호출해야 합니다. 또한 2단계 커밋의 초기 준비 단계에서 리소스 관리자가 기록한 해결되지 않은 트랜잭션만 다시 등록해야 합니다. 잘못된 시간에 이 메서드를 호출하려고 하면 잘못된 결과가 발생할 수 있습니다.

이 메서드를 사용하여 참가자를 다시 목록에 추가하면 트랜잭션의 결과(즉, IEnlistmentNotificationCommit 또는 Rollback )에 해당하는 2단계 메서드 InDoubt 가 적절하게 호출됩니다.

2단계 - 복구 완료

모든 재등록이 완료되면 리소스 관리자가 메서드를 호출합니다 RecoveryComplete . 이 메서드는 복구를 완료하고 리소스 관리자에 더 이상 의심할 여지 없는 트랜잭션이 없음을 트랜잭션 관리자에게 알립니다. 이렇게 하면 리소스 관리자가 메서드를 다시 호출 Reenlist 하지 않도록 보장합니다.

리소스 관리자는 새 트랜잭션에 참여하기 전에 모든 의심할 여지 없는 트랜잭션을 해결할 필요가 없습니다. 첫 번째 단계는 리소스 관리자가 트랜잭션 관리자와 관계를 설정한 후 언제든지 수행할 수 있지만 호출된 후 RecoveryComplete (2단계) 1단계를 다시 수행할 수 없습니다. 2단계는 트랜잭션 결과에 영향을 주지 않고 여러 번 반복할 수 있습니다.