COM & .NET Component Services

Synchronous Versus Asynchronous Components

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 queued component 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).

Changes in Transaction Semantics

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 ...