Queued Components and Transactions
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 ...
Get COM & .NET Component Services now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.