2단계 커밋 성능 고려 사항
TI(트랜잭션 통합자) 구성 요소가 트랜잭션 내에서 실행되면 TI 런타임 환경은 COM+ 환경의 Microsoft DTC(Distributed Transaction Coordinator)에 메시지를 보내 트랜잭션에 특수 유형의 LU 6.2 리소스 관리자로 참여합니다. TI는 호스트에 데이터 버퍼를 보내고 회신을 수신한 후 메서드를 호출하고 컨트롤을 SetComplete COM+로 반환합니다. 이 시점에서 클라이언트 애플리케이션 또는 TI를 구동하는 다른 구성 요소는 동일한 트랜잭션에도 포함된 다른 작업을 수행할 수 있습니다. 모든 리소스 관리자가 업데이트를 수행하고 를 발급 SetComplete하면 트랜잭션의 작성자(자동 트랜잭션에 대한 COM+ 자체일 수 있음)는 메서드를 DTC로 보냅니다 Commit . DTC는 TI 런타임 환경을 포함하여 모든 리소스 관리자에게 첫 번째 단계(Prepare) 메시지를 보냅니다. TI는 Prepare PS Header SNA 형식에 정의된 를 생성하고 호스트에 보냅니다. 호스트 업데이트가 유효하고 커밋될 수 있음을 나타내는 회신을 수신 RequestCommit 하고 이 정보를 DTC에 다시 전달합니다. DTC는 모든 리소스 관리자로부터 투표를 수집하며, 준비된 모든 경우 커밋 레코드를 로그에 강제로 작성하고 메시지를 보냅니다 Committed . 다시 말하지만 TI는 이를 로 SNA PS Header변환하고, 회신을 수신하고, 이를 DTC로 다시 변환합니다. 모든 것이 계획대로 작동하면 DTC는 트랜잭션을 롤백하고 APPC/LU 6.2 대화의 할당을 취소합니다.
참고
TI와 AP 모두 APPC 또는 CPI/C SYNCPT 동사에 대해 걱정할 필요가 없습니다. 트랜잭션 작성자가 "SyncPoint를 사용"하기로 결정하고, OLE 트랜잭션의 의미 체계로 표현되며, TI LU 6.2 분기뿐만 아니라 트랜잭션의 모든 참가자가 참여합니다. TI의 역할은 하위 수준입니다. TI는 DTC의 리소스 관리자 역할을 합니다. DTC에서 사용하는 COM 인터페이스와 호스트가 이해하는 SNA 프로토콜 간에 변환되어 프로토콜의 두 단계를 수행하고 DTC가 1단계와 2단계 간에 커밋 결정을 내릴 수 있도록 합니다.
성능 관점에서 호스트 업데이트의 원자성을 보장하면 상당한 피할 수 없는 오버헤드가 추가됩니다. 2PC(2단계 커밋)에 대한 호스트로의 왕복 메시지 흐름과 등록할 Windows 메시지 흐름, DTC 및 호스트의 트랜잭션 로깅(강제 디스크 쓰기)에 대한 두 가지 추가 왕복 메시지 흐름이 있습니다. 많은 비즈니스 논리 처리가 필요하지 않은 트랜잭션은 2PC가 없는 동일한 트랜잭션과 비교할 때 완료하는 데 두 배 이상 걸릴 수 있습니다.
ACID 트랜잭션을 지원하도록 TI 구성 요소를 구성해야 하는 유일한 경우는 연결된 TP(호스트 트랜잭션 프로그램)가 Windows 운영 체제의 리소스와 일관성을 유지해야 하는 중요 업무용 리소스를 수정하는 경우입니다. TP가 일관성을 보장해야 하는 리소스를 수정하지 않으면 TI 구성 요소를 트랜잭션을 지원하지 않음으로 구성하여 2PC가 시도되지 않도록 합니다. 그런 다음 TCP/IP 프로토콜도 자유롭게 사용할 수 있습니다. TCP/IP 프로토콜은 2PC를 지원하지 않습니다.
TI 구성 요소는 새 트랜잭션 필요로 구성해서는 안 됩니다. 즉, 호스트에 대해 트랜잭션을 원격으로 관리하고 새 트랜잭션을 만들고, 등록하고, 호스트와 2PC 교환을 수행하는 오버헤드가 발생하지만 TI 메서드는 그 자체로 트랜잭션이 됩니다. CICS 및 IMS가 자체 트랜잭션을 관리할 수 있도록 하는 것이 더 효율적입니다. Windows 운영 체제의 모든 업데이트는 해당 트랜잭션의 일부가 아니므로 독립적으로 커밋하거나 롤백합니다.
참고
동일한 서버의 추가 비즈니스 논리 처리는 처리량 제한을 낮추어 일부 CPU를 도용합니다. 그러나 전체 응답 시간 예산의 scope 비용이 상대적으로 적을 수 있습니다.