Transaction Scenarios
Applications differ greatly in their complexity and need for COM+ transactions support. To understand the COM+ transactions architecture and the needs it addresses, you should first examine a few generic transaction cases.
Single Object/Single Resource Transaction
Consider an application that comprises just one component instance, an object that processes a client’s request and accesses a single resource (such as a database) that takes part in a transaction. This situation is depicted in Figure 4-1. The application (in this case, the object) has to inform the resource when a transaction is started. This act is called enlisting the resource in the transaction. The object starts making calls on the resource interfaces, making changes to its state. However, at this point the resource should only record (log) the changes and not actually perform them.
If the object encounters no errors when executing a client’s request, then on completion it informs the resource that it should try to commit the changes. If the object encounters errors, it should instruct the resource to abort and roll back the changes. Even if the object wants to commit the transaction, any existing errors on the resource side might cause the transaction to abort.

Figure 4-1. Managing a transaction in a single object/single resource scenario
Note that only the application can request to commit ...