CS5226 Week 2

Principles of Transaction Management

Pang Hwee Hwa

School of Computing, NUS
panghh@comp.nus.edu.sg

H. Pang / NUS
 Outline

• Transaction concepts & protocols

• Performance impact of concurrency control

• Performance tuning

H. Pang / NUS
 Application
Programmer
(e.g., business analyst,
Data architect)

Application

Sophisticated
Application Query Processor
Programmer
(e.g., SAP admin)
Indexes Storage Subsystem

Concurrency Control Recovery

DBA,
Tuner
Operating System

Hardware
H. Pang / NUS [Processor(s), Disk(s), Memory]
 Transaction Concepts & Protocols

• Transaction
– A logical unit of database processing
– A sequence of begin, reads/writes, end
– Unit of recovery, consistency, concurrency

• Transaction Processing Systems

– Large databases with multiple users executing
database transactions
– Examples
• Banking systems, airline reservations, supermarket
checkouts, ...

H. Pang / NUS
 Transaction States

read-item,
write-item

begin- end-
transaction transaction Partially commit
Active Committed
Committed

abort
abort

Transition
Failed Terminated

STATE

H. Pang / NUS
 Interleaved Transactions

• A and B are concurrent transactions

A A

B B

Time
t1 t2 t3 t4 t5

H. Pang / NUS
 Transaction “Correctness”

• ACID properties
– Atomicity
– Consistency
– Isolation
– Durability

• Enforced by concurrency control and recovery

methods of the DBMS

H. Pang / NUS
 Serial Schedule

• Schedule
– A sequence of read & write operations from various transactions
– R1[X] W3[Y] R2[X] W2[Y] W1[X] W2[X]

• Serial schedule
– No interleaved operations from the participating transactions
– W3[Z] R3[Y] R1[X] W1[Y] R2[Y] W2[Z] W2[X]
– Always correct, but … so slow!

• A schedule that is equivalent to some serial schedule is

correct too

H. Pang / NUS
 Equivalent Schedules

• 2 schedules are equivalent if the transactions

– Read the same values
– Produce the same output
– Have the same effect on the database

• Examples
1. R1[X] W2[X] R3[Y] W1[Y] R2[Y] W3[Z] W2[Z]
2. W3[Z] R3[Y] R1[X] W1[Y] R2[Y] W2[Z] W2[X]
3. W2[X] R1[X] W1[Y] R2[Y] W3[Z] W2[Z] R3[Y]
• 1 and 2 are equivalent; not 3
H. Pang / NUS
 Serializable Schedule

Theorem
• A schedule is serializable if there is a serial
schedule such that for every conflicting pair of
operations, the two operations appear in the
same order in both schedules.

• 2 operations conflict if they are on the same

object and one is a write
• Example 1 is serializable

H. Pang / NUS
Concurrency Control Enforces Serializability

• Most commercial DBMS use protocols (a set of

rules) which when enforced by DBMS ensure
the serializability of all schedules in which
transactions participate.
– Serializability testing after execution is meaningless;
how to rectify?
– This done by Concurrency Control

H. Pang / NUS
 Concurrency Control Protocols

• Commercially accepted mechanisms

– Locking
– Timestamps

• Others mechanisms
– Multi-version and optimistic protocols

• Granularity issues

H. Pang / NUS
 Locking

• Locking is used to synchronize accesses by

concurrent transactions on data items
– A concept also found in operating systems and
concurrent programming

• A lock is a variable for a data item, that

describes the status of the item with respect to
allowable operations

H. Pang / NUS
 Types of Locks

• Binary locks
– Locked, or Unlocked
• Check before enter; wait when locked; lock after enter;
unlock after use (and wakeup one waiting transaction).
– Simple but too restrictive

• Read/Write locks in commercial DBMS

– read-locked R-lock W-lock
– write-locked R-lock Y N
– Unlocked
W-lock N N

H. Pang / NUS
 Read/Write Locking Scheme

• A transaction T must issue read-lock (X) or

write-lock before any read-item (X)
• T must issue write-lock (X) before any write-item
(X)
• T must issue unlock-item (X) after completing all
read-item (X) and write-item (X)
• T will not issue a read-lock (X) if T already holds
a read/write lock on X
• T will not issue write-lock (X) if T already holds a
write lock on X

H. Pang / NUS
 Does Locking Ensure Serializability?

T1 T2
read-lock (Y); read-lock (X);
Y unlocked read-item (Y); read-item (X); X unlocked
too early too early
unlock (Y); unlock (X);
write-lock (X); write-lock (Y);
read-item (X); read-item (Y);
X:=X+Y; Y:=X+Y;
write-item (X); write-item (Y);
unlock (X); unlock (Y);
Cannot serialize T1 and T2
H. Pang / NUS
 Need for Locking Protocol

• Locking alone does not ensure serializability!

• We need a locking protocol
• A set of rules that dictate the positioning of
locking and unlocking operations, thus
guaranteeing serializability

H. Pang / NUS
 Two-Phase Locking (2PL)

• A transaction follows the two-phase protocol if all

locking operations precede the first unlocking
operation

read-lock (X) read-lock (Y)

write-lock (X) unlock (X)
write-lock (Y) unlock (Y)

Phase 1: Growing Phase 2: Shrinking

H. Pang / NUS
 2PL Variants

• Basic 2PL
• Conservative 2PL
– Locking operations precede transaction execution
– Make sure can acquire necessary locks
• Strict 2PL
– Unlocking of write-locks after commit (or abort)
– Avoid cascading abort
• Rigorous 2PL
– Unlocking of all locks after commit (or abort)
H. Pang / NUS
 Limitations of 2PL

• Some serializable schedules may not be

permitted
– Performance not optimal
• 2PL (and locking in general) may cause
deadlocks and starvation
– Deadlock: no transactions can proceed
– Starvation: some transaction wait forever

H. Pang / NUS
 Lock Granularity

• Larger size - lower concurrency

• Smaller size - higher overhead

What is the best item Depends on the type of

size? transactions

Processing a mix of Multiple granularity locking

transactions? scheme, changing the size of
the data item dynamically

H. Pang / NUS
 Other CC Protocols

• Timestamp based
• Multi-version based
• Optimistic concurrency control
– No checking is done before or during transaction
execution
– The transaction is validated at the end of execution,
by checking if serializability has been violated

H. Pang / NUS
 Summary of Transaction Concepts

Baseline:
Transaction
Serial Schedule
Correctness

Other CC Protocols
A Strict 2PL
• Timestamp
C   • Multi-version
I 2PL • Optimistic
D 
Ideal:
Serializable Schedule

H. Pang / NUS
 Summary
To improve performance

Interleave transactions

Correctness: ACID

Serial schedule is correct

Serializable schedule is equivalent to some serial schedule

Concurrency control enforces serializability

2PL Optimistic Timestamping Multi-version

- Deadlock
- Starvation
- Granularity
H. Pang / NUS
Performance Impact of Concurrency Control

• Lock contention
• Deadlock

H. Pang / NUS
Performance Impact of Concurrency Control

• LONG transactions are

penalized

H. Pang / NUS