트랜잭션 모델

다음 구성 부분으로 이루어진 메시지 플로우를 고려해 볼 수 있습니다.

메시지 플로우가 메시지를 처리할 때 이벤트의 순서는 다음과 같을 수 있습니다.

  1. 메시지를 입력 큐에서 가져옵니다.
  2. 데이터베이스 테이블과 큐에서 데이터를 읽거나 씁니다.
  3. 시스템이 일시정지하고 다음 입력 메시지를 대기합니다.

이러한 순서의 이벤트는 테이블의 액세스 및 출력 메시지 쓰기를 구분하지 않습니다. 플로우가 일반적으로 일부 출력 메시지를 생성하는 것으로 간주되기는 하지만 실제로 이 작동과 데이터베이스 테이블을 갱신하는 작동과의 사이에는 차이가 없습니다. 두 경우 모두 시스템에 있는 데이터의 상태가 변경됩니다.

다음 다이어그램을 고려하십시오.
=====x=========x===x=======x=============x====x=====
1 2 3 4 5 6

위의 선은 시간이 경과하는 동안 시스템의 데이터를 나타냅니다. 시간 1에서 입력 큐에 메시지가 도착하고 해당 큐에서 메시지를 가져옵니다. 시간 2, 3, 4 및 5에서는 데이터베이스 테이블이 갱신되거나 큐에 쓰기가 이루어집니다. 이러한 상태의 변화는 x 기호로 표시됩니다. 마지막으로 시간 6에서 출력 메시지가 큐에서 출발하고 시스템이 일시정지합니다. 이들 이벤트 간에는 데이터의 상태가 변경되지 않으며 이는 = 기호로 표시됩니다.

이번에는 시스템 장애의 영향을 고려해 보십시오. 장애가 발생하면(예: 브로커가 실행되는 동안 시스템의 플러그가 뽑힘) 장애가 발생하기 전에 발생한 테이블과 큐 상태의 변경은 변경이 이루어지지만 장애 발생 이후에는 발생한 변경사항에 대해 변경이 이루어지지 않습니다. 예를 들어, 내 현재 계정 및 내 장기 주택 대출 계정 등의 지급이 현재 계정 테이블에서 차감되지만 장기 주택 담보 대출 계정 테이블에 쌓이지는 않는 경우와 같이, 이러한 상황은 받아들일 수 없을 가능성이 큽니다.

트랜잭션

이 문제점을 방지하기 위해 브로커, 큐잉 시스템과 데이터베이스는 트랜잭션 모델을 사용합니다. 이 경우는 처리가 진행되면서 추가 데이터가 저장되어 장애 이벤트 발생 시 원래의 상태가 복원될 수 있다는 것을 기초로 합니다. 이 데이터의 정확한 형식 및 데이터가 확보되는 확실한 방법은 중요하지 않습니다. 다음 다이어그램은 이 추가 데이터의 상태를 설명합니다.
=====x=========x===x=======x=============x====x=====
1 2 3 4 5 6

위의 선은 시간이 경과하는 동안 시스템의 추가 데이터를 나타냅니다. 시간 1에서 입력 큐에 메시지가 도착하고 해당 큐에서 메시지를 가져옵니다. 그 전에는 시스템에 추가 데이터가 없으며 이는 - 기호로 표시됩니다. 이 시간 이후에 해당 상태는 메시지가 필요할 경우 큐에 다시 넣어질 수 있도록 하기 위해 큐에서 메시지를 가져온다는 사실을 나타냅니다. 시간 2, 3, 4 및 5에서는 데이터베이스 테이블이 갱신되거나 큐에 쓰기가 이루어집니다. 다시 말해 추가 데이터의 상태가 변경되어, 테이블 및 큐의 변경사항을 필요 시 실행 취소할 수 있습니다. 마지막으로 시간 6에서 출력 메시지가 큐에서 출발하고 시스템이 일시정지하며, 시스템에는 다시 한 번 추가 데이터가 없습니다. 이들 이벤트 간에는 추가 데이터의 상태가 변경되지 않으며 이는 = 기호로 표시됩니다. 시간 1과 6 사이의 임의의 시간에 장애가 발생하면 추가 데이터가 시스템 데이터의 원래 상태로 복구하기 위해 사용되며, 실제로 출력 큐 중 어느 곳에도 쓰여지지 않고 테이블은 변경되지 않으며 입력 메시지는 입력 큐에서 가져와지지 않습니다. 장애가 발생하지 않으면 변경사항은 시간 6에서 영구적으로 적용됩니다. 즉 이후에 장애가 발생하면 실행 취소 조작으로 실행 취소가 이루어지지 않습니다.

이 모드의 조작은 통합 트랜잭션 모드로 알려져 있습니다. 트랜잭션의 정상적인 완료를 확약이라고 합니다. 성공하지 못한 완료는 롤백이라고 합니다. (통합 트랜잭션을 수행하는 길고 복잡한 설명은 XYZ 절을 참조하십시오. 이는 디폴트가 아니며 모든 데이터베이스 또는 큐잉 시스템에서 이를 지원하는 것은 아닙니다.)

통합되지 않은 보조 트랜잭션

통합 트랜잭션 모드 조작의 핵심 기능은 하나의 입력 메시지과 연관된 모든 큐 및 테이블의 변경사항이 장애가 발생한 위치 또는 시기와 관련 없이 모두 적용되거나 전혀 적용되지 않는다는 것이며 이것이 통합 트랜잭션의 가장 중요한 이점입니다. 그러나 이것이 모든 상황에 적용되지는 않습니다. 이러한 예외 상황에 대한 간단한 두 가지 예가 아래에 나와 있습니다.

이러한 요구사항을 충족하기 위해, WebSphere Message Broker는 큐와 테이블에서 쓰기가 별도의 트랜잭션으로 발생하도록 합니다. 다음 다이어그램에서 이에 대해 설명합니다.
MAIN -----x=========x===x=======x=============x====x-----
1 2 4 5 8 9
1st AUX --------------x======x========x------
3 6 7

윗줄은 전과 마찬가지로 기본 트랜잭션을 나타냅니다. 트랜잭션은 다소 추상적인 용어이지만 실제 사용 시에는 원래 상태를 복원하는 데 필요한 추가 데이터가 발생해야 한다는 점을 조정해 줍니다. 아랫줄은 보조 트랜잭션을 나타냅니다. 시간 3에서 테이블(또는 큐)에 갱신이 이루어집니다. 또다른 갱신이 시간 6에 이루어집니다. 시간 7에서 플로우는 보조 트랜잭션에서 일어나야 하는 모든 변경사항이 완료되었음을 확인하고 변경을 확약합니다.

시간 7 이전에 플로우에 장애가 발생하면 두 트랜잭션이 모두 롤백되므로 시스템의 상태는 변경되지 않습니다. 장애가 시간 7보다는 나중이지만 시간 9보다는 전에 발생할 경우 보조 트랜잭션은 확약되지만(이미 확약되어 있음) 기본 트랜잭션은 롤백됩니다. 시간 9까지 장애가 발생하지 않으면 장애는 발생하지 않으며 두 트랜잭션 모두 확약됩니다.

데이터베이스 보조 트랜잭션

하나의 보조 트랜잭션으로만 제한되는 것은 아니며 트랜잭션을 확약하는 것에만 제한되지도 않습니다. 데이터베이스 테이블에 많은 갱신이 이루어질 수 있으며 이러한 갱신사항은 확약되거나 롤백될 수 있습니다. 그 다음 동일한 데이터베이스 테이블 또는 다른 테이블을 추가적으로 변경한 다음 해당 변경사항을 확약하거나 롤백할 수 있습니다.

사용하는 각 데이터베이스에는 고유의 보조 트랜잭션이 있으므로 플로우가 다른 데이터베이스 인스턴스(예: 다른 데이터 소스 이름)에 속한 테이블을 갱신하는 경우 데이터베이스별로 보조 트랜잭션이 실행됩니다. 각각 개별적으로 확약 또는 롤백될 수 있습니다(필수에 가까움). 조작 완료 시(시간 9) 확약 또는 롤백되지 않은 모든 갱신은 처리의 완료 또는 실패, 즉 예외가 입력 노드에 수신되었는지 여부에 따라 브로커에 의해 자동으로 확약되거나 롤백됩니다.

AIX용 DB2와 같은 일부 데이터베이스 유형은 같은 데이터베이스 인스턴스에서 통합 및 통합되지 않은 트랜잭션 모두를 허용하지 않습니다. 이 경우 별도의 데이터베이스 인스턴스를 작성해야 합니다. 통합 트랜잭션용 데이터베이스 인스턴스 및 통합되지 않은 트랜잭션용 데이터베이스 인스턴스를 구성해야 합니다.

보조 데이터베이스 트랜잭션은 ESQL COMMIT 및 ROLLBACK문을 사용하여 확약 또는 롤백됩니다. 기본 트랜잭션 외부의 조작은 사용되는 개별 데이터베이스 명령문(예: INSERT 및 UPDATE문)에 UNCOORDINATED를 지정하여 확보합니다.

큐 보조 트랜잭션

위에서 설명한 데이터베이스의 성능이 모든 큐잉 시스템에 있는 것은 아닙니다. MQ의 경우 각각의 통합되지 않은 큐에서 읽기 또는 큐에 쓰기에 확약이 이루어질 수 있습니다. 그러므로 두 개의 메시지를 넣고 두 메시지 모두를 확약하거나 롤백할 수는 없습니다. 이것은 WebSphere Message Broker가 숨길 수 없는 시스템의 근본적인 제한사항입니다. 따라서 COMMIT 및 ROLLBACK문은 데이터베이스에서만 작동합니다.

노드

위의 설명은 플로우에 대해서만 설명하며 노드는 다루지 않습니다. 플로우를 노드로 나누는 방법은 원칙적으로 트랜잭션과는 관련이 없습니다. 임의의 수의 노드는 기본 및 보조 트랜잭션(수량 제한 없음)을 제한사항 없이 원하는 대로 갱신할 수 있습니다. 수행의 대상은 중요하지만 수행 방법은 중요하지 않습니다. 그러나 실제로, 다른 데이터 소스(VSAM, Queues)에는 더 많은 성능상의 한계가 있기 때문에 데이터베이스에서의 조작에 대해서만 이 원칙이 적용됩니다.

전혀 통합되지 않은 트랜잭션

모든 데이터베이스 갱신이 보조 트랜잭션 내에서만 수행되는 특수한 경우에 대해서도 언급되어야 합니다. 이 경우 메시지 플로우의 "통합 트랜잭션" 속성을 "아니오"로 설정할 수 있습니다. 이를 통해 기본 트랜잭션 외부의 모든 테이블 참조는 각 데이터베이스 조작에서 이를 지정해야 하는 번거로움을 덜 수 있습니다. 메시지 플로우의 흐름도 빨라집니다.

주: 이 경우에도 MQ 큐에 쓰기는 MQ 큐에서 입력 메시지 가져오기와 통합될 수 있습니다.
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 5월 12, 2006
ac07010_