Transaction Management

A COM+ transaction potentially comprises several players and involves a complex mix of oversight and protocol interaction. Once again, COM+ simplifies the process, by automatically organizing any number of disparate resources into an implicit transactional framework. The following sections describe each of the building blocks involved.

Resource Managers

Resource managers are responsible for, well, managing resources. Records in databases, messages in queues, and other such resources qualify for resource manager supervision. Products that are responsible for storing, retrieving, and persisting durable data, such as SQL Server and Oracle, are treated as COM+ Resource Managers. One of the most critical responsibilities of a COM+-compliant resource manager is that it support transactional updates. When transferring money, you need to know that account A was debited $100 and account B was credited $100, or that neither operation is going to take place. The problem becomes even more complex when the resources in question are not resident within the confines of a single resource manager. What then?

Microsoft Distributed Transaction Coordinator

MS DTC is Microsoft's Distributed Transaction Coordinator. It was introduced with SQL Server 6.5 as a means to manage distributed transactions involving several SQL databases. In this way, MS DTC acts as a transaction processing (TP) monitor on the Windows platform. The DTC creates a transaction object supporting the ITransaction interface to represent each new distributed transaction. Other interfaces support the two-phase commit process, which enables enlisted resource managers to vote on the success of their parts of the overall operation. One dissenting resource manager causes the whole transaction to abort, in which case DTC notifies the constituent resource managers that the entire transaction fails. If all the resource managers agree to commit the transaction, the DTC commits the distributed transaction, once again notifying all the interested parties.

COM+ components are insulated from the complexities of distributed transaction management and, in most cases, never need to invoke DTC interfaces directly. In fact, COM+ provides automatic DTC transaction creation, automatic resource manager DTC transaction enlistment, and a simple IObjectContext interface that objects use to commit or abort transactional operations.

Resource Dispensers

Resource dispensers are responsible for doling out resources to needy objects within the COM+ runtime. The resource dispenser may directly support the storage and management of the resource in question, as is the case with the shared property manager, or may simply pool resource connections to an external resource manager, as is the case with ODBC. In the later case, the resource dispenser is also obliged to enlist the resource manager operations in the transaction extant in the current context, if one exists.

Transaction Protocols

Of course, transactions have been around a long time and have cropped up somewhat independently on various platforms. This complicates matters somewhat. The COM+ programming environment provides support for several different transaction protocols, discussed in the following sections.

OLE Transactions

Microsoft bases almost all its services and architectures on COM these days. Thus COM is the basis for the OLE Transaction standard. OLE Transactions are native to MS DTC, SQL Server, and just about any other transactional Microsoft product.

XA Transactions

The X/Open UNIX standards body promotes its XA Transaction standard. XA Transactions are used extensively in many distributed environments, especially UNIX. Because this is the preferred transaction mechanism used by some of the largest database companies in the world (Oracle, Informix, Sybase, and others), it would be a tragedy to leave out XA transaction support in any product seeking to become the enterprise-enabling transactional component runtime of the millennium . Thus DTC supplies support for XA transactions.

As you might have guessed, there is, regrettably, a little more to it than that. Because Microsoft is more inclined to integrate and fully test the services of SQL Server than, say, Oracle 8, XA transaction configuration may take some work. Be sure to examine the COM+ Help system supplied with your version to ensure that you have the correct driver revisions before you attempt to use XA transactions in a COM+ system. The TestOracleXAConfig.exe command line utility (which comes with Oracle) enables you to check for correct Oracle database transaction support.

CICS and IMS Transactions

Now you're moving into alien territory. Not only do mainframes support their own unique transaction protocols, but they often also operate in a completely different network infrastructure. They were here first, so you can't blame them for that. Mainframes are the center of the transaction processing world because of their legendary reliability. So it really would be nice to allow a slick Web-based client, that calls a component running in a COM+ middle- tier server, to interact with the big iron. Fortunately, DTC supports LU 6.2 Sync Level 2, and with the help of Microsoft Host Integration (SNA) Server and COMTI, transactions can be distributed into the mainframe environment.