안정적인 메시징

메시지 전달은 두 개의 홉에서 발생합니다. 첫 번째 홉은 제작자의 메시지를 브로커의 물리적 대상으로 가져오고, 두 번째 홉은 물리적 대상의 메시지를 소비자에게 가져옵니다. 따라서 브로커로 이동하는 홉, 브로커가 실패할 때 브로커 메모리에 있는 홉 그리고 브로커에서 소비자로 이동하는 홉 중 하나에 해당할 경우 메시지가 손실될 수 있습니다. 안정적인 전달에서는 이러한 경우에도 전달이 실패하지 않습니다. 비지속성 메시지는 브로커가 실패할 경우 항상 손실될 수 있으므로 안정적인 전달은 지속성 메시지에만 적용됩니다.

다음 두 메커니즘을 사용하여 안정적인 전달을 확실히 합니다.

• 클라이언트는 확인 또는 트랜잭션을 사용하여 메시지가 성공적으로 생성 및 소비되는지 확인합니다.

• 브로커는 영구 저장소에 메시지를 저장할 수 있으므로 메시지가 소비되기 전에 브로커가 실패할 경우 저장된 메시지 복사본을 검색하여 다시 작업할 수 있습니다.

다음 절에서는 안정성을 보장하는 이러한 2가지 측면에 대해 설명합니다.

확인

확인은 클라이언트와 메시지 서비스 간에 안정적인 메시지 전달을 확인하기 위해 보내는 메시지입니다. 확인은 제작자와 소비자에서 서로 다르게 사용됩니다.

메시지 생성 시, 브로커는 메시지를 받아서 대상에 넣고 영구적으로 저장했음을 확인합니다. 제작자의 send() 메소드는 이 확인을 받을 때까지 차단됩니다. 이러한 확인은 지속성 메시지를 보낼 때 클라이언트에 대해 투명합니다.

메시지 소비 시, 클라이언트가 대상으로부터의 메시지 전달을 수신하고 메시지를 소비했음을 확인한 다음 브로커가 해당 대상에서 메시지를 삭제합니다. JMS는 서로 다른 안정성 정도를 나타내는 다양한 확인 모드를 지정합니다.

• AUTO_ACKNOWLEDGE 모드에서 세션은 클라이언트에서 소비하는 각 메시지를 자동으로 확인합니다. 브로커가 소비된 각 메시지에 대해 클라이언트 확인을 처리했음을 확인할 때까지 기다리는 동안 세션 스레드는 차단됩니다.

• CLIENT_ACKNOWLEDGE 모드에서 클라이언트는 메시지 객체의 acknowledge() 메소드를 호출하여 하나 이상의 메시지를 소비한 후 명시적으로 확인합니다. 이것은 세션이 메소드의 이전 호출 이후에 세션에 의해 소비된 모든 메시지를 확인하기 때문입니다. 또한 브로커가 클라이언트 확인을 처리했음을 확인할 때까지 세션 스레드는 차단됩니다.

  Message Queue는 클라이언트가 하나의 메시지에 대해서만 수신을 확인할 수 있는 메소드를 제공하여 이 모드를 확장합니다.

• DUPS_OK_ACKNOWLEDGE 모드에서 세션은 메시지를 10개 소비한 후 확인합니다. 이 모드에서는 브로커 확인이 필요하지 않으므로 브로커 확인이 완료될 때까지 세션 스레드가 차단되지 않습니다. 이 모드에서는 메시지가 손실되지 않지만 이름이 DUPS_OK이기 때문에 중복 메시지가 수신될 수 있습니다.

안정성보다는 성능을 더 고려하는 클라이언트를 위해 Message Queue 서비스는 NO_ACKNOWLEDGE 모드를 제공하여 JMS API를 확장합니다. 이 모드에서는 브로커가 클라이언트 확인을 추적하지 않기 때문에 소비자 클라이언트에서 메시지를 성공적으로 처리했는지 확인할 수 없습니다. 이 모드를 선택하면 비영구 가입자에게 보내는 비지속성 메시지에 대한 성능이 향상될 수 있습니다.

트랜잭션

트랜잭션은 하나 이상의 메시지 생성 및/또는 소비를 기본 단위로 묶는 방법입니다. 위에서 설명한 클라이언트 및 브로커 확인 프로세스는 트랜잭션에도 적용됩니다. 이 경우 클라이언트 런타임과 브로커 확인이 트랜잭션 수준에서 암시적으로 수행됩니다. 트랜잭션이 완결되면 브로커 확인이 자동으로 보내집니다.

세션은 트랜잭션된 세션으로 구성할 수 있으며, JMS API는 트랜잭션 초기화, 완결 또는 롤백을 위한 메소드를 제공합니다.

트랜잭션 내부에서 메시지를 생성하거나 소비하면 메시지 서비스는 다양한 발신 및 수신을 추적하여, JMS 클라이언트가 트랜잭션을 완결하도록 호출한 경우에만 작업을 완료합니다. 트랜잭션 내부에서 특정 발신 또는 수신 작업이 실패할 경우 예외가 발생합니다. 클라이언트 코드는 예외를 무시하거나 작업을 다시 시도하거나 전체 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다. 트랜잭션이 완결되면 성공적인 작업이 모두 완료됩니다. 트랜잭션이 롤백되면 성공적인 작업이 모두 취소됩니다.

트랜잭션의 범위는 항상 단일 세션입니다. 즉, 단일 세션 컨텍스트에서 수행되는 하나 이상의 제작자 또는 소비자 작업을 묶어 단일 트랜잭션으로 분류할 수 있습니다. 트랜잭션 범위가 단일 세션에 국한되므로 메시지 생성과 소비를 모두 총괄하는 종단간 트랜잭션은 만들 수 없습니다.

또한 JMS 사양은 분산 트랜잭션을 지원합니다. 즉, 메시지 생성 및 소비는 데이터베이스 시스템과 같은 다른 자원 관리자가 관련된 작업을 포함하는, 더 크고 분산된 트랜잭션의 일부가 될 수 있습니다. Java Systems Application Server에 제공된 것과 같은 트랜잭션 관리자는 분산 트랜잭션을 지원할 수 있어야 합니다.

분산 트랜잭션의 경우, 분산 트랜잭션 관리자는 JTA(Java Transaction API)인 XA Resource API 사양에 정의된 2단계 완결 프로토콜을 사용하여 여러 자원 관리자(메시지 서비스, 데이터베이스 관리자 등)가 수행하는 작업을 추적하고 관리합니다. Java에서 자원 관리자 및 분산 트랜잭션 관리자 간의 상호 작용은 JTA 사양에서 설명합니다.

분산 트랜잭션 지원은 메시징 클라이언트가 JTA에서 정의된 XAResource 인터페이스를 통해 분산 트랜잭션에 참여할 수 있음을 의미합니다. 이 인터페이스는 2단계 완결을 구현하는 여러 메소드를 정의합니다. 클라이언트측에서 API 호출이 이루어지는 동안 JMS 메시지 서비스는 분산 트랜잭션 내부의 다양한 발신 및 수신 작업을 추적하고 트랜잭션 상태를 추적하며 JTS(Java Transaction Service)가 제공하는 분산 트랜잭션 관리자와의 조정을 통해서만 메시징 작업을 완료합니다. 로컬 트랜잭션과 마찬가지로 클라이언트는 예외를 무시하거나 작업을 다시 시도하거나 전체 분산 트랜잭션을 롤백하는 방법으로 예외를 처리할 수 있습니다.

Message Queue는 Java Enterprise Edition 플랫폼에서 JMS 공급자로 사용되는 경우에 한해 분산 트랜잭션을 지원합니다. 분산 트랜잭션 사용 방법에 대한 자세한 내용은 Application Server 공급자가 제공한 설명서를 참조하십시오.

영구 저장소

안정성의 또 다른 측면은 메시지가 소비자에게 전달될 때까지 브로커가 지속성 메시지를 잃어버리지 않아야 한다는 것입니다. 즉, 메시지가 물리적 대상에 전달되면 브로커는 이를 영구 데이터 저장소에 저장해야 합니다. 어떤 이유로 브로커가 중단되는 경우, 브로커는 메시지를 나중에 복구하여 해당 소비자에게 전달할 수 있습니다.

브로커는 영구 가입을 영구히 저장해야 합니다. 그렇지 않으면, 오류 발생 시 브로커는 메시지가 주제 대상에 도달한 다음에 활성화되는 영구 가입자에게 메시지를 전달할 수 없습니다.

메시지 전달을 보장하려는 메시징 응용 프로그램은 메시지가 지속성을 갖도록 지정하고, 이를 영구 가입이 설정된 주제 대상이나 대기열 대상 중 하나로 전달해야 합니다.

3 장, Message Queue 서비스에서는 Message Queue 서비스에서 제공한 기본 메시지 저장소 그리고 관리자가 대체 저장소를 설정하고 구성하는 방법에 대해 설명합니다.