트랜잭션 메시징

Service Broker 프로그래밍 모델은 트랜잭션 메시징을 기초로 합니다. Service Broker와 관련된 모든 작업은 현재 트랜잭션의 일부입니다. Service Broker에서는 현재 트랜잭션이 커밋될 때까지 메시징 작업을 커밋하지 않습니다. 트랜잭션이 롤백될 경우 데이터베이스 엔진에서는 트랜잭션의 일부인 모든 메시징 작업도 롤백되도록 합니다. 응용 프로그램에서는 SQL Server 트랜잭션 관리의 일부로 메시징 작업을 관리합니다.

예를 들어 프로그램이 트랜잭션 내에서 메시지를 보내는 경우 Service Broker에서는 해당 프로그램이 트랜잭션을 커밋할 때까지 네트워크를 통해 메시지를 보내지 않습니다. 프로그램이 트랜잭션 내에서 메시지를 받는 경우 데이터베이스 엔진에서는 해당 프로그램이 트랜잭션을 커밋할 때까지 큐에서 메시지를 영구적으로 제거하지 않습니다.

트랜잭션 메시징을 사용하면 데이터베이스의 상태가 큐의 상태와 일관된 상태를 유지하도록 하여 강력하고 확장 가능한 응용 프로그램을 작성할 수 있습니다. 응용 프로그램에서 데이터베이스를 변경하고 메시지를 보내거나 받을 경우 데이터베이스 변경 및 메시징 작업도 동일한 트랜잭션의 일부가 됩니다. 트랜잭션이 롤백되면 데이터베이스 변경 및 메시징 작업도 모두 롤백되므로 두 작업은 모두 성공하거나 모두 실패합니다. Service Broker 모델에서 응용 프로그램은 트랜잭션 메시징을 사용하여 해당 응용 프로그램에서 보낸 메시지가 데이터베이스의 현재 상태를 반영하도록 합니다.

트랜잭션 메시징의 모든 이점을 활용하려면 메시징 작업이 메시지가 나타내는 데이터베이스 작업과 동일한 트랜잭션에서 발생하도록 응용 프로그램을 작성합니다. 예를 들어 주문을 처리하는 응용 프로그램에서는 단일 트랜잭션에서 주문에 대한 메시지를 받고 해당 주문으로 데이터베이스를 업데이트합니다.

응용 프로그램에서 메시지를 받는 트랜잭션과 데이터베이스를 업데이트하는 트랜잭션이 서로 다른 경우 데이터베이스 업데이트에 실패하면 메시지가 더 이상 없는데 해당 메시지에서 요청한 변경 작업은 아직 수행되지 않은 경우가 발생합니다. 이 경우 응용 프로그램에서는 Service Broker에서 제공하는 기본 이점 중 하나를 활용하지 못합니다. 특히 Service Broker는 모든 메시지가 순서대로 정확히 한 번씩 배달되도록 하고 그렇지 않을 경우 메시지 발신자가 Service Broker 오류 메시지에 대한 알림을 받을 수 있도록 합니다. 단, 이 예와 같이 큐에서 메시지를 영구적으로 제거하지만 메시지를 처리하지는 못하는 응용 프로그램의 경우는 예외입니다. 이러한 이점을 활용하지 않을 경우 응용 프로그램에는 발생할 수 있는 불일치를 처리하는 추가 코드를 포함해야 하며 그렇지 않으면 잘못된 결과가 발생할 수 있는 위험을 감수해야 합니다.

응용 프로그램에서 메시지를 처리하고 데이터베이스를 변경하지는 않을 경우에는 이러한 이점을 활용할 수 있습니다. 즉, 메시지가 성공적으로 처리됩니다. Service Broker를 사용하는 응용 프로그램에서는 메시지를 무시하도록 선택할 수도 있지만 응용 프로그램이 데이터베이스와의 연결을 잃거나 예기치 않게 종료되는 경우라도 실수로 메시지를 잃어서는 안 됩니다.