Transactions

• Concurrent execution of user programs is essential for

good DBMS performance.
• Because disk accesses are frequent, and relatively slow,
it is important to keep the CPU working on several user
programs concurrently.
• A user’s program may carry out many operations on the
data retrieved from the database, but the DBMS is only
concerned about what data is read/written from/to the
database.
• A transaction is the DBMS’s abstract view of a user
program: a sequence of reads and writes, which are
executed as a unit.

1
 Transaction Properties
Atomicity
• A very important property guaranteed by the DBMS for
all transactions is that they are atomic.
• That is, a user can think of a transaction as always
executing all its actions in one step, or not executing any
actions at all.
• DBMS logs all actions so that it can undo the actions of
aborted transactions.
• If it succeeds, the effects of write operations persist
(commit);
2
• If it fails, no effects of write operations persist (abort)
 Transaction Properties
Consistency
• Users are responsible for the consistency of their
transactions.
• Each transaction must leave the database in a
consistent state if the database is consistent when the
transaction begins.
• The DBMS will enforce ICs and other constraints
• Beyond this, the database does not really understand
the semantics of the data. (e.g., it does not understand
how the interest on a bank account is computed).
• Database consistency is the property that every
transaction sees a consistent database instance.
3
 Transaction Properties
Isolation
• Users submit transactions, and can think of each
transaction as executing by itself.
• Concurrency is achieved by the DBMS, which
interleaves actions (reads/writes of DB objects)
of various transactions.
• The net effect of several transactions should be
the same as if they are executed one after
another.
4
 Transaction Properties
Durability
• If transaction completes, its effects will persist in
the database.
• In particular, if the system crashes before effects
are written to disk, they will be redone.
• Recovery manager is responsible for this.

5
 ACID Properties
• Atomicity: Each transaction is executed completely or
not at all.
• Consistency: The execution of each transaction in
isolation maintains database consistency and results in a
database whose new state correctly models the new
state of the enterprise.
• Isolation: The concurrent execution of a set of
transactions in the database has the same effect as that
of some serial execution of the set of transactions. i.e.,
transactions are isolated or protected from the effects of
concurrently scheduling other transactions.
• Durability: The results of committed transactions are
permanent. The committed transactions should be
reflected in the database even if the system crashes
before all its changes are reflected on disk. 6
 Transaction States
partially committed
committed

active

failed aborted

7
 Transaction Schedule
• A transaction is seen by the DBMS as a series (or list) of
actions.
• These actions are reads or writes of an object: R(O),
W(O).
• In addition to reading and writing, a transaction should
specify commit or abort at the end: Commit, Abort.
• Transactions only interact with each other through
reads/writes.
• A database is a fixed collection of independent objects.
• A schedule is a list of actions (read, write, abort,
commit) for a set of transactions, and the order in which
they happen in the schedule is the same as in the
transaction. 8
 Schedules
• Consider two transactions:
– The first transaction is transferring $100 from
B’s account to A’s account.
– The second is crediting both accounts with a
6% interest payment.
• There is no guarantee that T1 will execute before
T2 or vice-versa, if both are submitted together.
However, the net effect must be equivalent to
these two transactions running serially in some
order.
9
Example

10
 Concurrent Schedule

S {R1 ( A), W1 ( A), R2 ( A), W2 ( A), R2 ( B ), W2 ( B ), R1 ( B ), W1 ( B )}

11
 Serial Schedule
• Serial schedule: Schedule that does not
interleave the actions of different transactions.
• Equivalent schedules: For any database state,
the effect (on the set of objects in the database)
of executing the first schedule is identical to the
effect of executing the second schedule.
• Serializable schedule: A schedule that is
equivalent to some serial execution of the
transactions.

12
 Concurrent Execution: Motivation
• Transaction may wait for I/O (Page reads from disk).
• CPU is idle - Disk I/O and CPU can function in parallel.
• CPU can be used to process another transaction.
• Concurrent execution - Reduces IDLE time and hence
increases system throughput.
• Long transaction and Short transaction - A short
transaction may end up scheduled behind a long
transaction. Without concurrent execution, the short
transaction takes a long time to complete unpredictable
response time.
• Throughput: Average number of transactions completed
in a given time.
• Response Time: Average time taken to complete a
13
transaction.
 Serializability
• Serializable Schedule: A serializable schedule S over a set of
committed transactions is a schedule whose effect on any
consistent database is guaranteed to be identical to that of some
complete serial schedule over S.
• Database instance after executing a serializable schedule S is
equivalent to executing the transactions of S in some serial order.
• Example: A serializable schedule and its equivalent serial schedule

14
 Conflict Serializability
• Consider a schedule S with two consecutive operations I i and Ij
of transactions Ti and Tj respectively (i ≠ j).
• We can swap Ii and Ij if they operate on different objects.
• If they operate on same object Q:
– Ii = R(Q) and Ij = R(Q): No conflict.
– Ii = R(Q) and Ij = W(Q): RW conflict (unrepeatable read)
– Ii = W(Q) and Ij = R(Q): WR conflict (dirty read)
– Ii = W(Q) and Ij = W(Q): WW conflict (overwriting
uncommitted data).
• We cannot swap Ii and Ij if they conflict, because their order is
important then. 15
 Conflicts: Examples

RW WR WW 16
 Conflict Serializability
• If a schedule S can be transformed into a schedule S’, by a series of
swaps of non-conflicting instructions, then S and S’ are conflict
equivalent.
• A schedule S is conflict serializable if it is conflict equivalent to some
serial schedule.
T1 T2 T1 T2
R(A) R(A)
W(A) W(A)
R(A) Conflict equivalent R(B)
R(B) W(B)
W(A) R(A)
W(B) W(A)
R(B) R(B)
17
W(B) W(B)
 Test for Conflict Serializability
• Construct a precedence graph G=(V, E) from schedule S. Each
transaction in S is a node in the graph. There is an edge in G
from Ti to Tj if
– Ti executes W(Q) before Tj executes R(Q).
– Ti executes R(Q) before Tj executes W(Q).
– Ti executes W(Q) before Tj executes W(Q).
• If G consists a cycle then S is not conflict serializable.
• If G consists an edge Ti to Tj, then in any serial schedule S’
equivalent to S, Ti must appear before Tj.
• The serializability order can be obtained using topological
sorting.
• A depth-first search based cycle detection algorithm has O(n2)
complexity. 18
Test for Conflict Serializability

cycle
T1 T2 T3
T1 T2
R(Q)
W(Q)
W(Q)
W(Q)
T3

Not conflict serializable19

Example: Topological Sorting
T1 T1
T1

T2 T3
T2 T3 OR

T3 T2

T4
T4 T4
No cycle
Equivalent serial schedules20
 View Serializability
• Two schedules S and S’ are called view equivalent if:
– For each object Q, if transaction Ti reads the initial
value of Q in S, then Ti also reads the initial value of Q
in S’.
– For each object Q, if transaction Ti executes R(Q) in S
and that value was produced by transaction Tj (if any),
then Ti also reads the value of Q produced by Tj in S’.
– For each object Q, the transaction (if any) that
performs the final W(Q) operation in S, must perform
the final W(Q) operation in S’ also.
• If a schedule S is view equivalent to any serial schedule
then S is called view serializable. 21
 View Serializability

T1 T2 T3 T1 T2 T3
R(Q) R(Q)
W(Q) W(Q)
W(Q) W(Q)
W(Q) W(Q)

Blind writes
View equivalent
22
Conflict and View Serializability
• Conflict serializability is stricter than view
serializability.

• All conflict serializable schedules are view

serializable.

• View serializable schedules with blind writes

may not be conflict serializable.

23
 Recoverable Schedule
• If in a schedule S, a transaction Ti fails, its effects must be
undone to ensure atomicity.
• If another transaction Tj reads an object written by Ti, then
Tj should be aborted also.
• If Tj commits first and then Ti fails, it is not possible to undo
the effects of Tj because it is already committed. Then the
schedule S is called non-recoverable.
• Non-recoverable schedules are not allowed.
• A schedule S is recoverable if for each pair of transactions
Ti and Tj such that Tj reads an object previously written by
Ti, the commit operation of Ti appears before the commit
operation of Tj.
24
Example: non-recoverable Schedule

T1 T2
R(A)
W(A)
R(A)
Commit
R(B)
Fail
25