DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
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 inconsistentwe 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 datacustomer details, create order, create order item, and so onwhere the data is in databases or files. It may also involve other sorts of units of workputting 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 backin 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:
Previous | Table of Contents | Next |