Concurrency Control by Versioning - Transaction Processing - page 275

Chapter 12
Concurrency Control by Versioning

All the concepts related to transactional isolation and concurrency control discussed
in the previous chapters pertain to a single-version database model in which for each
data item (identified by a unique key) in the logical database, only a single version,
namely, the most recent or the current version , of the data item is available at any
time. When a transaction is permitted, at the specified isolation level, to read or
update a data item, the database management system always provides the transaction
with the current version of the data item.
In this chapter we discuss an alternative model of a logical database, called the
multiversion database , in which besides the current version also older versions of
data items are kept available for transactions. The data-item versions are stamped
by the transaction identifiers of the transactions that created them, and the versions
of a data item are ordered by the commit times of those transactions. The main
motivation for this is that these older versions, which are all committed, can be
given to other transactions for reading without locks. Most of the major database
management systems now offer the option of running transactions under snapshot
isolation , an isolation level achieved by transient versioning of data items.
When the old versions of data items are stored permanently, a multiversion
database provides access to prior states of the database via historical “as of” queries.
Such accountability and traceability are needed in applications such as queryable
online database backup, banking-account auditing, trend analysis, and moving-
objects databases.

12.1 Transaction-Time Databases

The multiversion databases considered in this chapter are transaction-time
databases , meaning that each version of a data item is stamped with the commit
time of the transaction that created the version, or, actually, with the transaction