Transactional Messaging

The foundation of the Service Broker programming model is transactional messaging. Any

operation that involves Service Broker is part of the current transaction. Service Broker doesn’t

commit a messaging operation until the current transaction commits. If the transaction rolls

back, the Database Engine guarantees that all messaging operations that are part of the

transaction also roll back. An application manages messaging operations as part of managing

transactions.

For example, when a program sends a message within a transaction, Service Broker doesn’t

send the message over the network until the program commits the transaction. When a

program receives a message within a transaction, the Database Engine doesn’t permanently

remove the message from the queue until the program commits the transaction.

Transactional messaging helps you write robust, scalable applications by ensuring that the state

of the database remains consistent with the state of the queues. When an application makes a

change to the database and sends or receives a message, the change to the database and the

messaging operation are part of the same transaction. If the transaction rolls back, both the

change to the database and the messaging operation roll back. Both operations succeed, or

both operations fail. In the Service Broker model, an application uses transactional messaging

to guarantee that the messages sent by the application reflect the current state of the

database.

To take full advantage of transactional messaging, you write your applications so that

messaging operations occur in the same transaction as the database operations that the

messages represent. For example, an application that processes an order receives the message

for the order and updates the database with the order in a single transaction.

If the application instead receives the message in one transaction and updates the database in

a different transaction, a failure to update the database creates a situation where the message

no longer exists, but the change that the message requested hasn’t taken place. In this case,

the application doesn’t take advantage of one of the main benefits that Service Broker

provides. In particular, Service Broker guarantees that all messages are delivered exactly once,

in order, or the message sender is notified with a Service Broker error message. An application

that removes a message from the queue permanently, but fails to process the message as in

this example, breaks this guarantee. Without this guarantee, the application must contain

additional code to handle possible inconsistencies or run the risk of incorrect results.