Information Technology Reference
In-Depth Information
Battling terminology
In operating systems, we use the term consistency in two ways. In the context of
critical sections and transactions, we use “consistency” to refer to the idea of a system's
invariants being maintained (e.g., “are my data structures consistent?”) In the context of
distributed memory machines and distributed systems, we use “consistency” to refer to
the memory model—the order in which updates can become visible to reads (e.g., “are
my system's reads at different caches sequentially consistent?”).
Where there is potential confusion, we will use the terms transaction consistency or
memory model consistency.
14.1.3
Implementing transactions
The challenge with implementing transaction is that we want a group of related
writes to be atomic, but for persistent storage hardware like disks and flash, the
atomic operation is a single-sector or single-page write. So, we must devise a
way for a group of related writes to take effect when a single-sector write occurs.
If a system simply starts updating data structures in place, then it is vul-
nerable to a crash in the middle of a set of updates: the system has neither
the complete set of old items (to roll back) nor a complete set of new items (to
commit), so an untimely crash can force the system to violate atomicity.
Instead, a transactional system can persistently store all of a transaction's
intentions, the updates that will be made if the transaction commits, in some
Denition: intentions
separate location of persistent storage. Only when all intentions are stored and
the transaction commits should the system begin overwriting the target data
structures; if the overwrites are interrupted in the middle, then on recovery
the system can complete the transaction's updates using the persistently stored
intentions.
Redo logging
A common and very general way to implement transactions is redo logging. Redo
logging uses a persistent log for recording intentions and executes a transaction
Denition: redo logging
in three stages:
1. Prepare. Append all planned updates to the log.
This step can happen all at once, when the transaction begins to commit,
or it can happen over time, appending new updates to the log as the
transaction executes. What is essential is that all updates are safely stored
in the log before proceeding to the next step.
