The COM+ Catalog is a resource manager. When a component that takes part in a transaction tries to access the Catalog, the Catalog auto-enlists in that transaction. As a result, all the configuration changes made within the scope of that transaction will be committed or aborted as one atomic operation, even across multiple catalogs on multiple machines, according to the transaction success. The main advantage of having the COM+ Catalog take part in your transactions is that it enormously simplifies deployment on multiple machines. Imagine a situation in which you write an elaborate installation script that tries to access and install your product on multiple machines. The problem is that almost anything in a distributed installation scenario can go wrong—from network failures to security to disk space. Because all the installation attempts are scoped under one transaction, you can guarantee that all server machines are left with identical configurations—either the installation succeeded on all of them, or the changes were rolled back and the servers are left just as they were before you tried to install the product.

Another benefit of having the Catalog as a resource manager is dealing with potential contentions and conflicts between two different applications that try to access and modify the Catalog at the same time. To ensure the transaction’s isolation, when one transaction makes a change to the Catalog, the Catalog will block all writers from other transactions until the current transaction commits or aborts. (COM+ will abort the transaction if a deadlock situation exists because of the blocking.) While a transaction modifies the Catalog, readers from within that transaction will read the data as if it were committed. Readers from outside the transaction will not be blocked, and the data they see will not reflect any interim changes made within the first transaction until that transaction actually commits. You should avoid starting a new COM+ application (either programmatically or manually via the Component Services Explorer) that relies on information that is not yet committed.

One last point regarding transactions and the COM+ Catalog: you can programmatically invoke calls that access the filesystem, such as exporting a COM+ application. The problem is that the filesystem and the Windows Installer do not participate in transactions. If your transaction aborts, you will have to roll back those changes manually to maintain consistency.