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

Previous Table of Contents Next


What is a distributed transaction?

Now let us imagine that all these units of processing, instead of residing on the one machine, reside on several machines. Perhaps the data is split across machines so that the Customer file is on one machine, the Order and Order Item on another machine, the Stock is on another machine, and the Product on another machine.

We now have a distributed transaction. The units of work are distributed across machines and the data is distributed across machines.

Now let us make it even more complex and say that the data not only resides on more than one machine but is managed by different DBMSs. Perhaps the Customer database is held in an Oracle DBMS, the Order and Order Item database is held in a Sybase database, and the Stock database is managed by Informix. Maybe we even have duplicate customer data held in a DB2/6000 database.

A distributed transaction in this case not only runs on several possibly heterogeneous machines in a network but is also split across DBMSs. Now, most DBMSs can handle the update of data—distributed transactions—which handle data in their own DBMS, but the update of data in multiple DBMSs is tricky and the DBMSs cannot help you here. So, enter Distributed Transaction Processing middleware.

What is distributed transaction processing middleware?

Distributed Transaction Processing middleware manages transactions in a heterogeneous environment. The transactions themselves may involve:]

  the execution of distributed processes and/or
  the update of distributed data

The DTPM ensures that transactions are completed successfully or that the system is recovered to a consistent state if the transaction is unsuccessful. DCOM with its MTS service can be classified as Distributed Transaction Processing middleware.

To roll back or undo units of work, the software managing the transaction may have to coordinate the undoing of work with other software products that manage resources. These are called Resource managers.

Resource managers

In one of those annoyingly tautological definitions one often finds in textbooks, I will define a Resource Manager as a software product which manages resources. Any the wiser? No? Let us look at this, then, from another point of view.

Resource managers can be queue managers, DBMSs, file managers, even print queue managers. Queue managers manage queues (a resource), DBMSs manage databases (a resource), file managers manage files (a resource), print spool managers manage the print spool (the resource), and so on. Resources are thus any sort of external asset which could be accessed and used by a program.

DTPMs coordinate multiple resources and multiple Resource managers of different types (DBMS, and other file handling systems, for example), providing end-to-end management of the communication process. If any of these Resource managers fail—DBMS, queuing file, flat file, etc., the DTPM takes the necessary action to recover and put the data and system back into a consistent state. As most of you are probably aware, Resource managers such as DBMSs hold the details of updates in temporary holding files until the programmer issues the command to commit. When this command has been issued, the updates are applied. DTPMs coordinate the commit process; we will see how in the next sub-section.

Let us first look at an example to see how DTPMs and Resource managers work with one another. In the example below, the business transaction A updates data in two different DBMSs and data in a file, puts a message on a queue via a queue manager, and also includes a process, which must return with the reply that the processing was successful for the transaction to be deemed successful.

If, for example, the process didn’t complete successfully, one of the updates planned for the DBMS wasn’t correct, or the message couldn’t be put on the queue, the transaction A would be deemed to have failed in its entirety, and the DTPM would need to work with the Resource managers to ensure none of those updates held in temporary storage was actually committed. In other words, the DTPM would instruct the Resource managers to remove any updates in temporary storage:


Figure 13.6  Example

  the “updates in waiting” that the DBMS was keeping ready for the command to commit would be removed
  the “messages in waiting” that the queue manager was keeping ready for the command to commit would not be stored on file
  the updates in waiting that the file manager was keeping ready for the command to commit would be discarded

If, on the other hand, all the process X came back with a reply that it had succeeded, the DBMSs all said the updates could be applied OK if need be, and the file manager and queue manager also said that they, too, could update OK, the transaction would be deemed to be a success and the transaction would then be “committed.” In this case all the “updates in waiting” would be applied.


Previous Table of Contents Next