Transactions and

Serializability

Ramakrishnan & Gehrke

Chap. 16.1-16.3

Database Systems Implementation, Bongki Moon 1

Review: Core Functions of DBMS

So far, our focus has been mainly on efficiency.

In addition to providing fast access to data, ...

Protect mission-critical data.

Provide correct and highly available (7x24) access
in the presence of concurrent access by large and
diverse users.
– Heavy-duty transactions and ad-hoc queries

Survive various S/W and H/W failures.

Database Systems Implementation, Bongki Moon 2

1
 Why Have Concurrent Processes?

Better transaction throughput, response time via

better utilization of resources
– While one processes is doing a disk read, another can be
using the CPU or reading another disk.

A degree of fairness in access to resources.

DANGER! Concurrency could lead to incorrectness!
– Must carefully manage concurrent data access.
– There’s (much!) more here than the usual OS tricks!

Database Systems Implementation, Bongki Moon 3

Transactions

A transaction is typically an application program (written in

C/C++) with embedded SQL statements.

From the DBMS’s point of view, a transaction is a series of
the following actions:
– READs: DB object is read from disk into buffer page.
– WRITEs: DB object is written from buffer to disk.
– ABORT: Last action of a Xact that fails.
– COMMIT: Last action of a Xact that succeeds.

These are the only operations that can change the state of a
database.
– The effects of aborted Xacts must be undone (or rolled back)
completely.
– DB is modified permanently only by committed Xacts.

Database Systems Implementation, Bongki Moon 4

2
 Concurrency in a DBMS

Users submit transactions, and can think of each transaction as
executing by itself. (Give users such illusion.)
– Concurrency is achieved by the DBMS, which interleaves
actions (reads/writes of DB objects) of various transactions.
– Each transaction must leave the database in a consistent
state if the DB is consistent when the transaction begins.
 DBMS will enforce some Integrity Constraints (IC), depending on
the ICs declared in CREATE TABLE statements.
 Beyond this, the DBMS does not really understand the semantics of
the data. (e.g., it does not understand how the interest on a bank
account is computed).

Issues: Effect of interleaving transactions, and crashes.
Database Systems Implementation, Bongki Moon 5

Properties of Transactions (ACID)

Atomicity: Xact is all-or-nothing.
– If system crashes, partially done Xacts must be undone
or “rolled back”.

Consistency: If each Xact is consistent, and the DB
starts consistent, it ends up consistent.

Isolation: Xacts are shielded from the effects of
other concurrent Xacts.
– Concurrency is for performance; must not affect
meaning of each Xact.

Durability: If a Xact commits, its changes must
be guaranteed to survive crashes.
Database Systems Implementation, Bongki Moon 6

3
 Passing the ACID Test

Atomicity: Keep track of the changes made by each active

Xact; if a crash occurs undo the changes of partial Xacts.

Durability: Keep track of the changes made by each
committed Xact; if a crash occurs, redo the changes that
have not been written to disk.

Isolation: Ensure that an Xact only “sees”
(reads/overwrites) changes made by committed Xacts.

Consistency: Follows from the other three; may require
run-time triggers for integrity constraints.

Database Systems Implementation, Bongki Moon 7

Static Database Assumption

DB is a fixed collection of objects (units in which

info is written to/read from DB, e.g., pages).
– Assume that pages are not added or deleted. That is,
assume a fixed set of data pages.
– (Will relax this shortly.)

Database Systems Implementation, Bongki Moon 8

4
 Example: Balance Transfer

Consider two transactions:
T1: A=A+100, B=B-100
T2: Read(A), Read(B), Print(A+B)

T1 is transferring $100 from B’s account to A’s

account. T2 is reporting the sum of the balances.

For T1, a required invariant is A + B = A0 + B0.

However, at several points during T1, database is in
a temporarily inconsistent state. Do you see them?

T1: R(A), W(A), R(B), W(B).

Database Systems Implementation, Bongki Moon 9

Example: Inconsistent retrieval

There is no guarantee that T1 will execute before T2 or
vice-versa, if both are submitted together. They may be
interleaved too.
T1: A=A+100, B=B-100
T2: Read(A,B), Print A+B

T2 can see an inconsistent DB state.

– T2 may print A0+B0 or A0+B0+100.
– This is a violation of the Isolation Test.

The net effect of concurrent execution must be equivalent
to the two transactions running serially in some order.

Serializability is the formal notion of correctness for
concurrent execution.
Database Systems Implementation, Bongki Moon 10

5
 Schedule

A schedule is a list of actions (read, write, abort,
commit) of a set of transactions.
– Show how operations are interleaved.
T1 T2
oldest action
R(A)
W(A)
R(A)
R(B)
R(B)
W(B) newest action

Schedule: R1(A) W1(A) R2(A) R2(B) R1(B) W1(B)

Database Systems Implementation, Bongki Moon 11

Examples of Schedules

Consider the following two schedules.

T1: A=A+100, B=B-100

T3: A=1.06*A, B=1.06*B

T1: A=A+100, B=B-100

T3: A=1.06*A, B=1.06*B

Are they correct? In other words, is the result produced by each of the
schedules can be obtained by either of the serial schedules T1-then-T3
and T3-then-T1?

How do you know a schedule is correct?
• For a set of N transactions, there are N! serial schedules. You can’t
try all of them!!
Database Systems Implementation, Bongki Moon 12

6
 transfer add 6%
$100 from interest to
Conflicting Operations A to B
T1
A&B
T3
R(A)

Two operations by different W(A)
transactions conflict when they R(A)
access the same item, and at W(A)
least one of them is WRITE. Database is
inconsistent! R(B)

W1(A)-R3(A), W1(A)-W3(A),
W(B)
R3(B)-W1(B), W3(B)-R1(B), etc.
Commit
R(B)
W(B)
Commit
Database Systems Implementation, Bongki Moon 13

Anomalies by Conflicts

WR Conflicts (Dirty Read)

– T1 leaves database in an inconsistent state after W(A).
– T3 read A modified by an uncommitted transaction T1.

RW Conflicts (Unrepeatable Read)
– T3 overwrites what T1 read. (E.g., A)
– If T1 reads it again, it will see something new!
– Again, not equivalent to a serial execution.

WW Conflicts (Overwriting Uncommited Data)
– T3 overwrites what T1 wrote.

Any of these violates the Isolation Property.
Database Systems Implementation, Bongki Moon 14

7
 Serializable (SR) Schedules

Two schedules are equivalent if
(1) defined over the same set of Xacts and operations,
(2) same intra-xact order of operations, and
(3) same inter-xact order of conflicting operations.

Equivalent schedules:
S1: R1(A)→W1(A) →R1(B) →W1(B) →C1→R2(A) →R2(B) →C2
S2: R1(A) →W1(A) →R2(A) →R1(B) →W1(B) →C1→R2(B) →C2

A schedule is serializable if it is equivalent to some

serial schedule.
– S2 is serializable because S1 is a serial schedule.
Database Systems Implementation, Bongki Moon 15

Serializable Schedules (cont’d)

Is this schedule serializable?

R1(A) →W1(A) →R2(A) →R2(B) →C2→R1(B) →W1(B) →C1

Use Dependency Graph to determine the serializability.
– T1  T2 ∈ DG if O1(A) < O2(A) and O1 and O2 are conflicting
operations.

DBMS guarantees that all executed schedules will be
serializable, but makes no guarantees about which
particular serial order of Xacts is simulated.
– We don’t need to know which one of the N! serial schedules it is.
– We just need to know whether it is serializable or not.

Database Systems Implementation, Bongki Moon 16

8
 Problems with Aborted Transactions

The effects of all incomplete or aborted Xacts must be

completely undone, in order for serializability to be a
useful property!

Serializable schedule: Equivalent to a serial schedule of

committed Xacts.
– as if aborted Xacts never happened.

Two Issues:
– Cascading aborts
– Recoverability

Database Systems Implementation, Bongki Moon 17

T1 T2
R(A)
Cascading Aborts W(A)
R(A)
W(A)

WR conflicts & Aborts?

Abort of T1 requires abort of T2!

To avoid cascading aborts, a Xact must abort
read data only from committed Xacts.

A schedule is ACA (avoids cascading abort) if
whenever Tj reads x from Ti (i.e., Wi[x] < Rj[x]),
then it must be that ci < Rj[x].
– No Dirty Reads are allowed.

Database Systems Implementation, Bongki Moon 18

9
 T1 T2
R(A)
Recoverable Schedules W(A)
R(A)

Abort of T1 requires abort of T2!
W(A)
– But T2 has already committed!
commit

To be recoverable, a Xact commits only
after all the Xacts it depends on commit. abort

A schedule is RC (recoverable) if whenever Tj reads
from Ti (i.e., Wi[x] < Rj[x]), it must be that ci < cj.
– Unlike ACA, Dirty Reads are allowed.

Real systems typically ensure that only
recoverable schedules arise (through locking).

Database Systems Implementation, Bongki Moon 19

Strict Schedules

With WW conflicts, undoing an aborted Xact with

before-values is difficult.
– T2 overwrites a value that T1 writes; then T1 aborts.
– When T1’s “remembered” values are restored, we lost
T2’s write!

To avoid this, Xacts only read/write changes of
terminated Xacts.

A schedule is ST (strict) if whenever wi[x] < oj[x],
it must be either ai < oj[x] or ci < oj[x].

Database Systems Implementation, Bongki Moon 20

10
 Relationships between Schedules

Serial ⊂ Strict ⊂ ACA ⊂ RC, Serial ⊂ Serializable

Serializable ⊄ Strict, Strict ⊄ Serializable.
Database Systems Implementation, Bongki Moon 21

Summary

Concept of transaction central to DBMS CC.

Transactions and the ACID properties:
– C & I are handled by concurrency control.
– A & D coming soon with logging & recovery.

Concurrency Control
– Guarantees Consistency and Isolation, given Atomicity.

Logging and Recovery
– Guarantees Atomicity and Durability.

Serial execution is our model of correctness.
– Schedule must be equivalent to some serial execution of Xactions.

Desirable properties of schedules: SR, RC, ACA, Strict (ST).

Database Systems Implementation, Bongki Moon 22

11