By now you have probably come to appreciate the elegance of using queued components and the great ease with which you can turn a synchronous component and its client code to asynchronous.
However, although it is technically possible to use the same
components both synchronously (using
CoCreateInstance( ) to create it) or asynchronously (using the
queued moniker), the likelihood that a component
will be used in both cases is low for the following reasons: using a
introduces changes in the semantics of the transactions the component
will take part in, and using a queued component implies a change in
the client program workflow. You simply cannot use the same
synchronous execution sequence logic. The rest of this section
elaborates on these two reasons. These arguments were first presented
in Roger Session’s book COM+ and the Battle for the
Middle Tier (John Wiley & Sons, 2000).
Suppose your online store does not use queued components. When the customer places an order, the Store object uses the Order and the Shipment objects synchronously. All the order and shipment database updates that these objects perform are under the umbrella of one transaction. Both databases are consulted regarding committing the transaction (see Figure 8-12).
Figure 8-12. Synchronous invocation scopes all operations ...