11.4. 트랜잭션 결과

트랜잭션에는 다음 세 가지 결과가 있습니다.

트랜잭션 참가자가 커밋하면 새 상태가 지속됩니다. 트랜잭션과 관련된 작업을 수행하는 참가자가 새 상태를 생성합니다. 가장 일반적인 예는 트랜잭션 멤버가 데이터베이스에 레코드를 쓸 때입니다.

커밋 후 트랜잭션 코디네이터에서 트랜잭션에 대한 정보가 제거되고 새로 작성된 상태가 이제 지속적 상태가 됩니다.

트랜잭션 참가자는 트랜잭션이 시작되기 전에 상태를 반영하도록 해당 상태를 복원하여 롤백합니다. 롤백 후 상태는 트랜잭션이 시작되지 않은 경우와 동일합니다.

추론적 결과 또는 비원형 결과는 트랜잭션의 참가자의 결정이 트랜잭션 관리자의 결정과 다른 상황입니다. 복구로 인해 시스템에 대한 무결성이 손실될 수 있으며, 일반적으로 문제를 해결하기 위해 사람의 개입이 필요합니다. 여기에 의존하는 코드를 작성하지 마십시오.

일반적으로 복구 결과는 2-단계 커밋(2PC) 프로토콜의 두 번째 단계에서 발생합니다. 드물지만 이 결과는 1PC에서 발생할 수 있습니다. 이러한 문제는 주로 기본 서버의 기본 하드웨어 또는 통신 하위 시스템에 장애가 발생하기 때문입니다.

트랜잭션 관리자 및 전체 충돌 복구를 통해서도 다양한 하위 시스템 또는 리소스의 시간 초과로 인해 복구가 가능합니다. 일부 형태의 분산 계약이 필요한 모든 시스템에서는 시스템의 일부가 글로벌 결과의 관점에서 다양해지는 상황에서 발생할 수 있습니다.

다음과 같은 네 가지 유형의 추론 결과가 있습니다.

heuristic rollback

커밋 작업은 리소스를 커밋할 수 없었지만 모든 참가자가 롤백할 수 있었기 때문에 원자적 결과가 계속 달성되었습니다.

Huristic 커밋

모든 참가자가 단독으로 커밋되었기 때문에 시도한 롤백 작업이 실패했습니다. 예를 들어 코디네이터가 트랜잭션을 성공적으로 준비할 수 있지만 로그 업데이트 실패와 같은 측면의 실패로 인해 롤백하기로 결정하는 경우 발생할 수 있습니다. 참여자들이 약속하기로 결정할 수도 있습니다.

heuristic 혼합

일부 참가자는 약속하고 다른 참가자도 롤백했습니다.

추론적 위험

일부 업데이트의 배치는 알 수 없습니다. 알려진 사람들에게는 모두 커밋되었거나 모두 롤백되어 있습니다.

UserTransaction 클래스 메서드에 의해 throw된 예외에 대한 자세한 내용은 UserTransaction API Javadoc를 참조하십시오.