Transactional Messaging

Applies To: Windows Server 2008

Transactional messaging

Sending and receiving applications can indicate that they want to send or retrieve messages within the context of a transaction, known as transactional messaging. Sending or retrieving messages outside the context of a transaction is referred to as non-transactional messaging. Transactional message is only used when you want to perform several tasks in such as way that all tasks, including non-Message Queuing operations, will all succeed or all fail.

Transactions are characterized by their ACID (atomicity, consistency, isolation, durability) properties:

• Atomicity. Atomicity refers to the all-or-nothing behavior of a transaction. When a transaction consists of a series of actions, all the actions are treated as a single operation that is either completed successfully or not run at all.

• Consistency. Transactions transform a system from one valid state to another.

• Isolation. Multiple transactions that are run concurrently have no effect on one another during their execution. It appears to each transaction that the other transactions are run either before or after it.

• Durability. After transactions are run, their effects are permanent despite system or network failures.

When transactional messaging is used, the sending or receiving application has the opportunity to commit the transaction (all the operations have succeeded), or to abort the transaction (one of the operations failed) so all changes are rolled back. When a transaction is aborted all operations are rolled back to their state prior to when the transaction was invoked.

When sending messages within a transaction, all the messages are sent together and in the order they were sent, or they are not sent at all. Message Queuing guarantees that all messages sent within the transaction will arrive exactly once if they can be delivered, and in the order that they were sent. When retrieving messages within a transaction, all the messages are either removed from the queue if the transaction is committed or they are placed back in the queue in their original position in the queue if the transaction is aborted. Note that transactional messages cannot be sent to a multicast address, and that peeking at messages has no relevance to transactional messaging.

In Message Queuing, a transaction can encompass multiple sending and receiving operations. However, the same message cannot be sent and received within a single transaction. In a case where a transaction consists of sending multiple messages, either all the messages are transmitted in the order in which they were sent (if the transaction is committed), or none of the messages are transmitted (if the transaction is aborted). If multiple messages are sent to the same queue, Message Queuing guarantees that they arrive in the destination queue exactly once and in the order in which they were sent within the transaction. For more information, see Sending Transactional Messages to Multiple Destinations.

Message order

Messages that are to be delivered in the order in which they were sent belong to the same message stream. Each message in a stream carries a sequence number, identifying the message in the stream, and a previous number, which denotes the sequence number of a previous message in the stream. The message whose sequence number equals the previous number of a message must be present in the destination queue before the message can be delivered. The first message in a stream always has a previous number value of zero(0).

Likewise, a transaction can consist of removing multiple messages from a queue. The messages are removed from the queue only if and when the transaction is committed; otherwise, they are returned to the queue and can be subsequently read in the context of another transaction.

In addition, Message Queuing guarantees that messages sent in consecutive transactions initiated from the same computer to the same destination queue will arrive in the order in which the transactions were committed. Moreover, as in the other cases of sending transactional messages, each message, if it arrives at the destination queue, will arrive exactly once.

Transaction performance

Transactional messaging is slower than non-transactional messaging because messages are written to disk more than once and greater computer resources are required. Transactional messages can be sent only to transactional queues on the local computer or a remote computer (and non-transactional messages cannot be sent to transactional queues). When messages are received within a transaction, they can be retrieved only from a local transactional queue. However, messages can be retrieved in non-transactional operations from local and remote transactional queues.

In the general case, there are two ways to implement transactional messaging, as follows:

• As external transactions

• As internal transactions

External transactions

External transactions are used if resources other than those that Message Queuing can provide need to be part of the transaction. They are coordinated by the Microsoft Distributed Transaction Coordinator (MSDTC), which is part of Component Services. Message Queuing then serves as a resource manager under the control of MSDTC. Using MSDTC as the transaction manager for Message Queuing, transaction-based applications can be implemented, ensuring that all actions either all succeed or all fail. For example, a Message Queuing application can send a message and update a database in the same transaction. MSDTC ensures that either both actions succeed (both actions are committed) or neither action is run (both actions are aborted). MSDTC is automatically installed on each computer during Windows Vista® and Windows Server® 2008 family operating system installation for local transactions. To enable network DTC access required for Message Queuing transactions across the network, see Enable Network DTC Access.

You can use external transactions to send or receive a message that is part of any COM-compliant resource operation and to send or receive multiple messages that are part of a single transaction.

COM+ Transactions

When your application is running in the COM+ (Component Services) environment, Message Queuing can send and receive messages within a COM+ transaction by using the current COM+ transaction object if it is available. Message Queuing, COM+ (Component Services), and DTC work together for this type of transaction.

XA-Compliant Transactions

Message Queuing can work in transaction systems that have an XA-compliant transaction manager. Because of this, DTC is used as a transaction process monitor and Message Queuing is a resource manager.

Internal transactions

Because they have less overhead, internal transactions run much faster than external transactions coordinated by the DTC. Use internal transactions if there is no need to coordinate Message Queuing operations with operations involving external resources that require the use of the DTC. Message Queuing provides a transaction coordinator that supports only itself as a resource manager.

You can use internal transactions to do the following:

• Ensure that a message is delivered only once (called exactly-once delivery).

• Ensure that all messages sent from one computer to another are delivered in order (called in-order delivery).

• Using acknowledgments, confirm that the transaction was successful (messages were received). You can also use acknowledgments to confirm that messages reached (or were removed from) the destination queue.

There is a special type of internal transaction that Message Queuing provides when sending a single message:

Single-message transactions

When sending a single message, Message Queuing provides a single-message transaction that implicitly uses the Message Queuing internal transaction, and consists of a single operation performed on a single message. A single-message transaction can be used to request guaranteed exactly-once delivery of a single message sent to a transactional queue. The single-message transaction provides the best performance of all transaction types for sending a message. In addition to exactly-once delivery, a single-message transaction is faster than an external transaction.

Order acknowledgment messages for transactional HTTP messages

Transactional messages are to be delivered exactly once and in the order in which they are sent. When transactional messages are sent over HTTP from the internal network of an enterprise to the Internet, the internal name of the sender's order queue must be translated into a logical address using a mapping to direct the order acknowledgment messages from the receiving computer outside the sender's enterprise, back to the sender's order queue. For more information, see HTTP Message Redirection.