| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

In summary

In this section we have looked at transactions, distributed transactions, Resource managers, locking, distributed two-phase commit, and the XA standard. We will now look at MTS and how distributed transaction processing works in this specific service.

Microsoft Transaction server and the Transaction manager

The specific component within MTS which handles Distributed Transaction Processing is called the Transaction manager or, at one time, Distributed Transaction Coordinator (DTC). The Transaction manager is geared towards supporting transaction control of both database updates and object calls. A “transaction” can thus be defined as being a set of both Resource manager calls and object calls.

Platforms

MTS currently runs only on Windows NT and 95, although the services can be invoked from a browser via an Internet Web server as we saw in the chapter on DCOM and the Internet. Clients can be Windows NT Workstation, Windows NT Server, or Windows 95. The servers must run on Windows NT Server.

Architecture

Transaction managers cooperate to manage transactions spanning multiple machines. Resource managers can exist on many nodes. Each local Transaction manager takes responsibility for that node’s Resource Manager. When the transaction is initiated, the two Transaction managers establish a relationship. These ingoing and outgoing relationships form a tree of Transaction manager relationships called the “commit tree” with Resource managers being part of the tree. When a distributed transaction commits or aborts, the commands flow outward on the tree. The root Transaction manager of the commit tree is the commit coordinator. It makes the decision whether to commit or abort.

As a consequence of this architecture, the Transaction manager cannot handle nested transactions, but can handle chained transactions (objects calling objects, calling objects).

Database connection pools

The database connection pool capability was added to ODBC 3 and is thus a feature of this component, but it can be used—is used—by Transaction Server. The DCP establishes and manages a set of sessions between the Transaction Server environment and the database. Rather than establishing database connections on a request-by-request basis from the application, ODBC 3 sets up a pool of reusable preconnected sessions. Application components make standard ODBC calls, but the resource dispenser allocates new connections from the shared pool.

Figure 13.8 The Commit tree

The Database connection pool manager avoids the server/client’s having to set up connections with the DBMSs and manage them within the server code. It also avoids the overhead of having one connection per server. Furthermore, the processing overhead incurred when connections are created and terminated occurs only once within Transaction server initialization and termination. Thus, the purpose of the Database connection pool is primarily to save the programmer time in coding but also to improve performance and make database access more efficient.

Standards

The Transaction manager of MTS uses the same conceptual model as the X/Open DTP model of distributed transaction processing but is based on Microsoft’s own object-based transaction processing protocol they have termed OLETX.

XA is a procedural API, based interface and Transaction Server is object based, thus Microsoft decided—much as the OMG did with CORBA— that an object-based interface was needed between the Resource manager and the Transaction manager (Transaction server). They thus invented OLETX—a different protocol from that used by CORBA (OTS) and different from XA.

Clearly, this is not an entirely satisfactory solution as it stands, as no Resource manager currently works with OLETX, and any move by the Resource manager vendors to produce an implementation for their product that works with OLETX is likely to mean a lot of additional work for them. But this is not the whole picture.

Microsoft has to use an object-based interface internally because its Transaction manager is component based, and it is clear that Microsoft hopes Resource managers will eventually come around to their way of thinking and build implementations of OLETX for their products. In the meantime, however, they have to provide a solution that works with XA, so the solution they use internally is to use a “driver” to map from OLETX to XA within Transaction server. The diagram below shows how this works, by using the original X/Open DTP diagram as the basis, with the additional components Microsoft is using added in.

Thus, as long as the DBMS is XA compliant, Microsoft is able to use the OLETX to XA driver/mapper to map from OLETX to XA internally within Transaction manager. In fact, Microsoft (Redmond) stated to us that, “The fact we did an OLETX to XA mapper is irrelevant. It is an implementation detail; all the customer needs to know is that we support XA.”

Figure 13.9 OLETX and XA

Cedar-The diagram also shows Cedar support for CICS on MVS.

A transaction in CICS is a unit of work, but it is also the context in which a program runs, or the “policy” attached to the program. Transactions are defined by the program name, the security level, the users that may use the transaction, the priority, and the hours of the day in which the program may run. If a program has a different security level, for example, or different priority, it is a different transaction. Each transaction in an application is given a transaction identifier (or transaction code)—a four-character code.

Transactions are not explicitly started and terminated using BEGIN TRANS-ACTION and COMMIT or ABORT commands as they are in other products. When a CICS application starts running, it is automatically presumed to be within a transaction. When the application terminates and returns control to CICS, CICS itself issues the Commit—a SYNCPOINT in CICS terminology. Hence the origins of the protocol, used to handle two-phase commit Synclevel2—the only one of three protocols provided by IBM that supports two-phase commit.

As we saw in the chapter on Cedar, Cedar translates the calls—the OLETX calls—to CICS Synclevel2 calls so that CICS applications can be included within transactions. Microsoft’s SNA Server is used to bridge the network protocols.

TIP and OSI TP-Microsoft also intends to support other “standards.” One specific “standard” mentioned includes Transaction Internet Protocol (TIP). TIP was in fact jointly developed by Microsoft and Tandem and is a protocol that can be used over the Internet—the complete reference implementation is based on Java. The IETF has formed a TIP working group which includes Bull, Tandem, DEC, and SNI. The specification has been sent to the IETF, and an interoperability demonstration was produced early 1997. Support is also planned for OSI TP.

Previous | Table of Contents | Next