CS262A Reading Summary

CS262A Reading Summary 2

Transaction Models (excerpt from Gray and Reuter's Transaction Processing: Concepts and Techniques)

Feng Zhou
9/5/2002

This part of the book first describes the nature of atomic actions. After that the classic definition and properties of flat transaction are discussed. Finally limitations and some modifications to the classic transaction model are presented. Main points in the text include,

Transactions are used to provide general-purpose ACID support. Atomic operations sometimes come for free, sometimes are very hard/impossible to achieve.
Atomicity includes two aspects of meaning: a) when and how the results of the operation are made accessible to other operations; b) How can unsuccessful operation be rolled back without side effects.
Single disk writes are often seen as atomic, but they are not. To make it appears atomic, we have several ways: read-after-write, duplexed write and logged write.
Actions can be categorized into 3 groups: a) unprotected actions are not atomic. They must be controlled by application environment or protected within a protected action to make the whole operation atomic; b) protected actions are building blocks of reliable applications; c) real actions can not be "rolled-back". So they need special treatment.
Flat transaction is the classic but still most popular model for transactions. It has the ACID properties. They are called flat because there is only one layer of control.
There are scenarios where flat transactions are awkward. Examples are complex updates and bulk updates. The former can be supported by savepoints or by nested transactions. The latter can be supported by chained transactions or sagas.

One question about the text:

The part about atomic actions put a lot of words on the issue of disk writes. It says that the controller may return normally without data being written correctly, and proposes to use "read-after-write" to solve the problem. However, a lot of checks are done by the disk hardware. So the probability that this kind of error would happen compared to the price you pay with "read-after-write" is so tiny. I don't see when this will be useful.

Principles of Transaction-Oriented Database Recovery

Theo Haerder and Adreas Reuter

This paper describes a taxonomy for classifying implementation techniques for database recovery. By using only 4 criteria (3 of them are binary), most implementations can be categorized and analyzed. The paper discussed pros and cons of some combination of the four criteria and existing implementations. Thus the authors successfuly consolidates all kinds of algorithms and techniques used in database recovery and present a clear overview of the literature.

First two parts of the paper include these enlightening points:

Transaction is a way to model a sequence of related interaction with the database. It has the ACID property and can have three outcomes: COMMIT, User ABORT and System ABORT. The ratio of the second is rather constant while the ratio of the third is related to the DBMS design and application.
The possible failure we have to deal with are transaction failure, system failure and media failure. The first two should be handled by transaction recovery. The last should be handled by archive recovery.
Most database systems can be put into a basic 5 layer mapping model. The layers are nonprecedural access, navigational access, record management, propagation control and file management. This layering results in three different view of a running database, i.e. current database - the user view, materialized database - what DBMS sees after a restart and physical database - all information on permanent storage. This leads to an important concept called propagation, which is the process of transferring content of current database to materialized database. Based on whether propagation is done in place, propagation can be categorized into ATOMIC and ¬ATOMIC.

One major flaw.
The author seemed to think ATOMIC is naturally more elegant than and could finally replace ¬ATOMIC, which was then widely used in commercial DB products. "Shadow page" in System R is among the ATOMIC side, which turned out to be a bad idea. To my knowledge most DBMSes now use ¬ATOMIC. This again proves that there are cases where simpler and more "brute-force" methods can be more effective than more elegant and sophisticated ones.