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

Previous | Table of Contents | Next

Distributed two-phase commit

So, we now have all our Resource managers, locks in place ready to update the transaction, and they are told to commit. What happens next? All products that support distributed transactions use a process known as two-phase commit.

In the first phase of the commit, the DTPM asks each Resource manager if it is ready to commit. If the reply from any of the Resource managers is no, the DTPM gives all the Resource managers the command to abort. They then remove the “updates in waiting” from their logs.

If one or more of the Resource managers did not reply because, for example, the line went down, the DTPM holds the instructions to abort in its own log file. Once the line or DBMS is online again, the DTPM gives the instructions to abort, and these remaining Resource managers will remove their updates in waiting.

If the reply is given from all Resource managers that they can commit, the DTPM then enters the second phase of the commit process—hence the expression two-phase commit. In this phase the DTPM tells all Resource managers to finally commit and they apply the updates in waiting to make them permanent. Once made permanent the locks are removed. There are some added complexities to this process, but we will have a look at them in the context of MTS itself, as each DTPM tends to handle the more complex problems differently.

Standards

As we have seen in the above explanation, it is essential that the distributed transaction processing middleware and the Resource manager communicate with one another. The whole success of the two-phase commit and distributed transaction process is dependent, in fact, upon the communication that takes place between the Resource manager and the DTPM.

It is, therefore, not surprising that the protocol between the two types of product is the subject of standardization. What is perhaps especially good news is that the DTPMs agree on the standard and so do most Resource manager vendors.

At last, a standard which vendors agree on. And, even better news, it works!

The standard was defined by the X/Open Group and is called the X/Open DTP (Distributed Transaction Processing) standard. The X/Open DTP standard provides a framework to build heterogeneous distributed transaction processing systems and was developed by X/Open’s Distributed Transaction Processing Working Group (DTPWG). The standard defines a model used by all the vendors of DTPMs and Resource managers that defines the interfaces between the products.

The diagram they use is the one shown below.

Figure 13.7 X/Open DTP standard

The application communicates with the Resource manager using its normal API—SQL in the case of a relational DBMS such as Oracle or Sybase, some other Data Manipulation Language (DML) in the case of file managers, and commands such as GET and PUT in the case of queue managers. The application communicates with the DTPM (the Transaction manager part) using its API. There aren’t really any standards here, although X/Open does include XATMI, TX, plus others. This, too, doesn’t really matter from your point of view as a developer unless you would like all the products to have a common API you use. Overall, it doesn’t actually affect the working of the products.

The key interface is between the Resource manager and the Transaction manager, and this is the one that has to be standard. It is called the XA interface. The programmer does not need to know the XA interface exists. All synchronization, commit, and rollback actions are coordinated by the Transaction manager via the XA interface.

The standard is defined as a specification—not source code, so each Resource manager vendor and each DTPM vendor has to build his own implementation of the standard. This does mean that no assumptions can be made by the vendors on whether their product works with other products. One Resource manager vendor may produce an XA implementation that works with DTPM A, but his implementation may not work with DTPM B. The implementations do have to be tested and there may be different versions.

The DBMSs that definitely support the XA standard and also work with all DTPMs that support the standard currently are Oracle, Informix, MS SQL Server, and DB2/6000. Gresham also provide a product called ISAM-XA, which is an XA-compliant Resource manager for ISAM files. This, too, appears to be able to work with all DTPMs that use XA. ISAM-XA incorporates before and after image logging, checkpointing, record level locking, deadlock detection, and buffer management. It includes APIs for both C and COBOL, as well as support for MicroFocus’s COBOL ISAM access verbs. ISAM-XA runs on Unix.

MQSeries (the queue manager in the product) also supports the XA standard so it, too, can act as a Resource manager with all DTPMs. BEA is planning to add XA support in their Message Queue Manager BEAmessageQ. Microsoft’s MSMQ is not yet XA compliant, but as it is very new this is probably not surprising. Microsoft does have plans to make it XA compliant in the future.

Gresham also supplies an XA conformant spooler/printer product, which we believe all DTPMs that support XA can support. Sybase and Ingres have XA components, but there seems to be some doubt as to whether these components completely conform to the XA specification. Some of the DTPM vendors stated that they could work with Sybase and Ingres, and others stated that they were still working on providing support for these two DBMSs.

Previous | Table of Contents | Next