CS5226 Week 2
Principles of Transaction Management
Pang Hwee Hwa
School of Computing, NUS
panghh@[Link]
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
