컴퓨팅 초기에는 분산 트랜잭션이 필요하지 않았습니다. 애플리케이션의 수가 증가함에 따라 데이터의 동기화가 중요한 문제가 되었습니다. 기업은 데이터 흐름 측면에서 동기화된 시스템을 유지하기 위해 많은 비용을 지불했습니다. 그 결과 XA(eXtended Architecture)라고 하는 2단계 커밋 프로토콜이 등장했습니다. 이 프로토콜은 전역 트랜잭션 처리를 위해 ACID와 유사한 속성을 제공합니다. 이 기사를 통해 XA 트랜잭션의 세부 사항과 Spring 프레임워크에서 XA 트랜잭션의 사용에 대해 설명하려고 합니다.

2단계 커밋 프로토콜은 분산 시스템을 위한 원자적 커밋 프로토콜입니다. 이 프로토콜은 이름에서 알 수 있듯이 두 단계로 구성됩니다. 첫 번째 단계는 트랜잭션 관리자가 모든 트랜잭션 리소스를 조정하여 커밋하거나 중단하는 커밋 요청 단계입니다. 커밋 단계에서 트랜잭션 관리자는 각 트랜잭션 리소스의 투표에 따라 커밋 또는 중단하여 작업을 완료하기로 결정합니다. 다음으로 2PC 프로토콜의 구현 세부 사항으로 넘어갈 것입니다.

2PC를 통한 Java + .NET 상호 운용성에 대한 리소스는 여기를 참조하십시오.

XA 트랜잭션에는 각 XA 리소스에 대한 글로벌 트랜잭션 ID와 로컬 트랜잭션 ID(xid)가 필요합니다. 각 XA 리소스는 start(xid) 메서드를 통해 XA Manager에 등록됩니다. 이 메서드는 XA 리소스가 트랜잭션에 참여하고 있음을 알려줍니다(작업 준비). 그 후 2PC 프로토콜의 첫 번째 단계는 prepare(xid) 메서드를 호출하여 구현됩니다. 이 메서드는 XA 리소스에서 OK 또는 ABORT 투표를 요청합니다. XA Manager는 각 XA 리소스로부터 투표를 받은 후 모든 XA 리소스가 OK를 보내면 커밋(xid) 작업을 실행하고 XA 리소스가 ABORT를 보내면 롤백(xid)을 실행하기로 결정합니다. 마지막으로 각 XA Resource에 대해 end(xid) 메소드를 호출하여 트랜잭션이 완료되었음을 알려줍니다. 더 잘 이해하려면 그림을 보십시오. XA 트랜잭션 구현에 대한 배경 지식을 구축하면서 다음으로 더 깊이 들어가 이 명령을 입력하는 방법을 살펴보겠습니다. 이 명령은 실패 및 가능한 솔루션입니다.


네트워크 손실, 시스템 다운 및 일부 관리자 실수로 인해 오류가 언제든지 발생할 수 있습니다. XA 트랜잭션에서 우리는 이러한 실패를 발생한 단계에 따라 분류합니다. 첫 번째 실패 단계는 프로토콜이 시작되기 전입니다. 이것은 시스템이 롤백이나 어떤 종류의 작업을 수행할 필요가 없는 단순한 오류입니다. 우리는 그 특정 순간에만 수술을 하지 않습니다. 두 번째 유형 이 명령 이 명령은 시간 초과 정책을 사용하여 롤백으로 쉽게 처리할 수 있는 준비(커밋-요청) 단계에서 실패 명령이 발생할 수 있습니다. 마지막으로 불완전한 롤백 및 체인 문제로 인해 발생할 수 있는 커밋 단계 실패가 있습니다. 위의 모든 상황에서 트랜잭션 관리자는 문제를 복구하려고 합니다. 다음으로 트랜잭션 관리자가 실패를 극복하는 방법을 살펴보겠습니다.

복구 시 트랜잭션 관리자는 각 XA 리소스의 복구 메소드를 호출합니다. XA 리소스는 로그를 추적하고 최신 상태를 다시 작성하려고 시도합니다. 트랜잭션 관리자는 필요한 롤백 작업을 호출하고 임무를 수행합니다. 이 과정이 행복한 길처럼 보일 수 있지만 로그가 손상되는 등 문제가 되는 예외적인 상황이 많이 있습니다. 이러한 상황에서 트랜잭션 관리자는 문제를 해결하기 위해 몇 가지 경험적 방법을 따릅니다. 또한 복구 프로세스는 적용하기 전에 작업 로그를 작성하는 미리 쓰기 로그에 따라 다릅니다. 성능 문제에서 이러한 로그는 자체 형식(직렬화를 사용하지 않음)으로 작성되며 시스템은 가능하면 일괄 처리하는 것이 좋습니다. 다음으로 Spring 프레임워크에 의한 XA 트랜잭션 지원이라는 재미있는 부분으로 이동합니다.

Spring 프레임워크는 웹 및 독립형 애플리케이션을 개발할 수 있는 광범위한 환경을 제공합니다. 제공하는 다른 유틸리티와 마찬가지로 XA 트랜잭션도 Spring에서 지원됩니다. 그러나 이 지원은 기본 구현이 아니며 최대 절전 모드, 웹 컨테이너 또는 XA 트랜잭션 관리를 제공하는 프레임워크가 필요합니다. Spring에는 트랜잭션 관리 유틸리티를 제공하고 세부 정보를 숨기는 JtaTransactionManager가 있습니다. 이런 식으로 동시에 업데이트되는 여러 DataSource에 대한 트랜잭션 관리를 가질 수 있습니다. XA 트랜잭션 관리를 사용하는 경우 XA 트랜잭션에 대한 최대 절전 모드 및 웹 컨테이너 지원이 잘 문서화되어 있으므로 언급할 필요가 없습니다. 그러나 XA 트랜잭션을 제공하는 프레임워크로 작업하는 것은 혼란스러울 수 있습니다. 따라서 Bitronix Transaction Manager를 소개하면서 이 게시물을 계속하겠습니다.

Bitronix는 트랜잭션 관리에 대한 우수한 지원을 제공하면서 쉽게 구성됩니다. 독립 실행형 응용 프로그램에서는 일반적으로 사용되지 않지만 다음과 같이 독립 실행형 응용 프로그램에 대한 구성을 제공하려고 합니다.

이제 다음과 같이 구성할 수 있는 여러 데이터 소스를 가질 수 있습니다. 각 데이터 소스에는 고유한 uniqueName 속성이 있어야 합니다. 아래 구성은 Oracle용이며 다른 데이터베이스는 다른 구성을 가질 수 있습니다. 기타 자세한 사항은 Bitronix 웹사이트에서 확인할 수 있습니다.

요약하자면 XA 트랜잭션, 기본 프로토콜 및 Bitronix 트랜잭션 관리가 독립 실행형 애플리케이션에서 Spring과 통합되는 것이 무엇인지 설명하려고 했습니다. 확장하기 위해 XA 트랜잭션은 동시에 다른 데이터 소스를 수정하는 기능을 제공합니다. 또한 XA 트랜잭션은 웹 컨테이너 또는 프레임워크와 같은 최대 절전 모드에서 지원됩니다. 그럼에도 불구하고 트랜잭션 관리자를 구성해야 하는 독립 실행형 애플리케이션에 트랜잭션 관리를 통합해야 할 수도 있습니다. 결과적으로 XA 트랜잭션은 여러 데이터 소스에 대한 일관된 작업을 제공하고 회사에서 이를 활용합니다.
이 기사가 How to Do XA Transactions (2 Phase Commit): A Simple Guide에 도움이 되었기를 바랍니다. 다른 질문이 있으시면 기꺼이 답변해 드리겠습니다. 아래 섹션에 문의하십시오. 공유하는 것을 잊지 마세요. signalfix.net 가족과 친구들과 함께!