As mentioned before, MSMQ is a resource manager. By default, when COM+ creates the application and retry queues, they are all transactional queues; they auto-enlist in the transaction that adds or removes a message to or from the queue.

The recorder and the listener are COM+ components installed in the COM+ Utilities application—a library application that is part of every Windows 2000 installation. These components are configured to require a transaction and take part in an existing transaction, or spawn a new one if none exists. (COM+ will not let you change the Utilities application components settings). Every time a client uses queued components, three transactions are involved—recording the calls, delivering the message to the application queue, and replaying the calls.

You can see this concept work with the online store (see Figure 8-9); all the calls made by the Store object on the Shipment recorder are packaged into one message and placed in an intermediate recorder queue. These calls were made in the scope of the transaction that accepted the order parameters from the customer (Transaction 1). Since MSMQ is a resource manager, the recorder queue rolls back and rejects the message if the order transaction is aborted.

MSMQ then has to transfer the message to the queued component application queue, potentially across the network. MSMQ creates a new transaction for the transfer, and both the source and the destination queues participate in it. If the transfer was unsuccessful, the transaction aborts, the queues roll back, and the message remains in the recorder queue. This action avoids a partial success situation, in which the message is removed from the source queue, but never added to the destination queue. This transaction is called Transaction 2 in Figure 8-9.

Figure 8-9.  The three transactions involved when a client uses queued components

Once the message is safely in the application queue, the listener starts a new transaction for removing it and playing it back to the component (called Transaction 3 in Figure 8-9). If the invocation fails, the application queue rollback moves it to the first retry queue, instead of adding it back to the application queue, to detect a potential poison message.

Usually you take the MSMQ transfer transaction for granted and omit it from your design documents. If you use a response object, the response object playback would be in a transaction of its own because it is just another queued component (see Figure 8-10).

Figure 8-10.  The transaction involved when using a response object

A word of caution when configuring the transactional setting of a queued component: avoid configuring your queued component to require a new transaction of its own. If you configure your component’s transaction setting to have Requires New, the recorder is in a separate transaction from that of the client, and MSMQ accepts the recorded calls and posts them to the application queue even if the original client transaction fails (see Figure 8-11).

Figure 8-11. Avoid configuring a queued component to require a new transaction

A similar inconsistency may exist if you configure the application queue as a nontransactional queue, as MSMQ removes the message from the queue even if the Shipment transaction is aborted.

You should always set the transaction setting of your queued component to Required—that is what will be necessary in most business situations.