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

Previous Table of Contents Next


Distributed Transaction Processing Support

This section is going to be quite a long one as it is the main service provided by MTS and also the most difficult one to understand. I will start by giving you an explanation of what distributed transaction processing actually is, how it works, and the standards on which it relies, and then we will look at how MTS actually works.

I will start, however, by getting back to basics.

What is a transaction?

A transaction is a unit of work that, when complete, leaves the computer system and its data in a consistent state, in other words, a sort of integrity unit. For example, a business transaction that records an order might involve the update of customer data, the creation of order and order item data, the update of stock data (to reserve stock to fulfill the order), and the creation of delivery details (so that the order gets delivered). If any part of this business transaction fails, the data will be inconsistent—we may have an order without item details, a stock record which does not reflect the goods reserved from it, a delivery going to the wrong customer address, or an order without delivery details, which, as a consequence, never gets delivered.

Those of us that have done data modeling know that the logic of a transaction is often driven by the structure of the data in the database. For example: A customer may have an order, and the order must specify the customer. The Order must have Order Items, and the Order Items must show the Order and the Goods they were for. Order Items are split into Deliveries. Deliveries are reserved against stock. Some Products may not have been ordered.


Figure 13.5  Data model of order processing data

Some stock items may have no deliveries reserved against them. Stock items each describe what product is in stock. Some products may not be in stock. The database structure thus defines the rules of the transaction and the integrity of the data which must be preserved.

A transaction involves a series of smaller units of work which together make up the transaction as a whole. As we have seen in the example, the transaction may involve the update of data—customer details, create order, create order item, and so on—where the data is in databases or files. It may also involve other sorts of units of work—putting messages on queues, putting print out on a print spooler, and so on.

You may also be in the unfortunate position of having duplicate data in your organization, and, as such, the transaction will then involve units of work which update all of this duplicate data, for example, customer data in one database and customer data in another database. In a transaction, all of these smaller units of work have to be completed for the data to be consistent and for the business unit of work to be deemed “complete.”

If any smaller unit of work should fail, the work already completed by the other units of work has to be rolled back—in effect undone. The processing within a transaction is thus organized around an “all or nothing approach.” It all has to be completed or none of it must appear to have been completed, which leads us to what are termed the ACID properties.

The ACID Properties

The ACID properties define the rules of transaction processing:

  A—atomicity—if a transaction’s work is interrupted by a failure, any partially complete results must be undone. The system must ensure that either all or none of the operations that make up a transaction are performed—the transaction either commits or aborts.
  C—consistency—transactions are assumed to perform the correct transformations of the abstract system state. This property is thus in the hands of the programmer, and the programmer must define what the operations are that constitute a correct transformation or transaction.
  I—isolation—transactions are allowed to execute concurrently, but the results must be the same as if the transactions executed serially. Concurrently executing transactions cannot produce inconsistencies. In this way, a programmer can cause temporary inconsistencies during the execution of a transaction, knowing that these partial modifications will never be visible.
  D—durability—once a transaction commits, its updates must be permanent. The new state of objects updated must be preserved, even in the case of hardware or software failures.


Previous Table of Contents Next