So What Makes a Transaction

The subject is best considered in terms of money and something familiar, like an IOU. Consider you and a friend are going to exchange an IOU and some money. You would mutually agree the amount that was going to be exchanged and your friend would write an IOU ("I Owe You") as you opened your wallet and got the money ready. This is the PREPARE phase. Once you had done this you would exchange the IOU and the money. This is the COMMIT phase. What happens, however, if you do not have enough money? The exchange of the IOU and the money does not take place. This is an ABORT.

It is worth looking at the properties of such a transaction. They define the nature of the beast. Firstly the transaction is Atomic, it cannot be sub-divided. The money may not be given if there is no IOU and the IOU may not be given without money. The transaction is Consistent, the offering of the IOU will always be replied with money, the offering of money will always be replied with an IOU. The transaction is Isolated. The exchange of the money and the IOU do not depend on any third party. Finally there is Durability, the money once exchanged is stored safely and so is the IOU. These four properties yield the pleasing acronym, ACID.

Not enough money? Would you consider an IOU?

We can take this money/IOU example further. Consider that you do not have enough money to satisfy your friend's IOU. You could write an IOU yourself and get money from a second friend. Is this a single transaction or is it two? Well it's sort of both.

Firstly, consider it as a single transaction. We could all agree to organize our prepare phase. This would involve, as before, the readying of money and the writing of IOUs (in this case there would be two of them). At the commit phase the money and IOUs would all be transfered. Should, for any reason, any party to this transaction not be in a position to complete it then everybody could back out. Money would be returned to wallets and IOUs ripped up.

Now consider it as at least two interlinked transactions. Our first friend may not be in a position to give us an IOU. This first part of the whole transaction has failed. We, at the centre, on the other hand, do make the exchange with our second friend, giving them our IOU in return receiving money. The second part of the transaction has succeeded. If the first part fails, the second part can proceed. However, if the second part fails we want to rollback the whole transaction regardless of what happens, we would be short of funds.

There is structure here, for although that part of the transaction can proceed normally if our first friend cannot participate the whole transaction cannot proceed if our second friend, the ultimate source of the cash cannot provide the supplemental money. Such a structured transaction with transactions within transactions is an example of a Nested Transaction.

Turning now to Computers. Using the above as an example we can see that there is a clear protocol, called a two-phase commit protocol which governs the way we and our friends conduct business. After we have prepared to exchange money or IOUs we have a vote to say whether we can do it or not. In the computer world it is the responsibility of a transaction management program to collect all the votes and to allow the whole transaction to proceed or fail. Using transactions which are known bracketed units of work allows exceptions or failures to be accommodated so that distributed parties either perform exchanges or remain in a known stable state.

The pleasing ACID acronym was first introduced in a review paper [Haërder & Reuter] in 1983.

Date: 1999/10/06 14:24:02