1. CS 440 Database Management Systems
Lecture 8: Concurrency Control

2. Concurrent access to data
Flight (fltNo, fltDate, seatNo, seatStatus)
Database: seats 22A and 22B are available.
John checks for availability and gets seat 22A
John books seat 22A
Mary checks for availability and gets seat 22B
Mary books seat 22B
Database: seats 22A and 22B are reserved.

3. Concurrent access to data: problems
Database: seats 22A and 22B are available.
John checks for availability and gets seat 22A
Mary checks for availability and gets seat 22A
John books seat 22A
Mary books seat 22A
Database: double booking on 22A!!!
Database is not consistent.
Solution: Run John’s before Mary’s (or vice versa)
serial schedule

4. Serial schedules
Database: seats 22A and 22B are available.
Admin scans Flight to generate some reports.
Mary checks the flights for tomorrow.
Nobody can use the database until Admin is done!!
How to run programs concurrently without them messing up each other’s results?
It takes a long time!

5. Transaction a “program” of atomic database operations.
atomic unit of database transformation.
START TRANSACTION
SQL-statement 1;
SQL-statement 2; …
SQL-statement n;
COMMIT;

6. The ACID properties
A tomicity: All actions in the Xact happen, or none happen.
C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent.
I solation: Execution of one Xact is isolated from that of other Xacts.
D urability: If a Xact commits, its effects persist.

7. Atomicity Balance transfer from Acct. 170 to Acct. 103:
check if account #170 has at least $200.
if #170 does not have enough fund => abort transaction
reduce the balance of #170 by $200.
check eligibility of #103, if not eligible => abort transaction
increase the balance of #103 by $200.
commit
roll_back command to abort the transaction
database system undoes all transaction’s modifications.

8. Atomicity Balance transfer from Acct. 170 to Acct. 103:
check if account #170 has at least $200.
reduce the balance of #170 by $200.
increase the balance of #103 by $200.
commit
Power outage in before SQL statement #3
transaction aborts
violates atomicity
database system should automatically undo all transaction’s modifications.

9. Isolation Database: double booking on 22A!!
Database: seats 22A and 22B are available.
John checks for availability and gets seat 22A
Mary checks for availability and gets seat 22A
John books seat 22A
Mary books seat 22A
Database: double booking on 22A!!
Concurrency control:
ensures that transactions are interleaved correctly.

10. Durability Balance transfer from Acct. 170 to Acct. 103:
check if account 170 has at least $200.
reduce the balance of 170 by $200.
increase the balance of 103 by $200.
commit
Database system says commit was successful, but the data is in buffer.
Power outage right after commit
modifications of the transaction are gone!
violates Durability
Database system must make sure that the effects of committed transactions persist.

11. The ACID properties
A tomicity: All actions in the Xact happen, or none happen.
C onsistency: If each Xact is consistent, and the DB starts consistent, it ends up consistent.
I solation: Execution of one Xact is isolated from that of other Xacts.
D urability: If a Xact commits, its effects persist.
Today’s topic

12. Transaction Interleaving
Before: A = 0, B = 0, then?
Correct schedule? Wrong schedule? Why?
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
A = A * 2
read(B)
B = B + 1
write(B)
read (B)
B = B * 2
write (B)
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
A = A * 2
read(B)
B = B * 2
write(B)
read (B)
B = B + 1
write (B)
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
read(B)
B = B + 1
write(B)
A = A * 2
B = B * 2
schedule 1
schedule 2
schedule 3

13. Transaction Interleaving
Schedule 1 (interleaved, more concurrent) = Schedule 3 (serial)
(A=0,B=0) --- T1 --> (A=1,B=1) -- T2 --> (A=2,B=2)
Consistency and isolation: transform DB in serial
Serializable schedule: a concurrent schedule that impacts DB like a serial schedule.
How to check if a concurrent schedule is serializable?
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
A = A * 2
read(B)
B = B + 1
write(B)
read (B)
B = B * 2
write (B)
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
read(B)
B = B + 1
write(B)
A = A * 2
B = B * 2
schedule 3
schedule 1

14. Use conflicting operations
We denote operations of transaction i as writei or readi.
Conflicting operations:
operations from different transactions such that:
two writes of the same data item: writei(A); witej(A).
a read and a write on the same data item: readi(A); writej(A).
Change the relative order of conflicting operators => change the final state of DB.
A serializable schedule has the same order of conflicting operators as a serial schedule.
they access the same data item and at least one of them is a write operation.
No conflict between read operations.

15. Serialization graph
Define dependencies between transactions with conflicting operations
Serialization (precedence) graph: Ti --> Tj for a dependency from Ti to Tj
Serializable if serialization graph does not have any cycle
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
A = A * 2
read(B)
B = B + 1
write(B)
read (B)
B = B * 2
write (B)
Xact T1 Xact T2
read(A)
A = A + 1
write(A)
A = A * 2
read(B)
B = B * 2
write(B)
read (B)
B = B + 1
write (B) T1 T1 T2 T2
schedule 1
schedule 2

16. Guaranteeing isolation
Scheduler guarantees serializability
restricts the access of transactions on data items.
enforces some order on conflicting operations.
Two approaches:
Pessimistic: There are many conflicting transactions.
Optimistic: There are a few conflicting transactions.

17. Locking Protocol A “protocol” for accessing data
well-formed transactions lock/unlock “access units” before/after using them
lock manager grants/manages locks
Goals of locking protocol
ensure serializability
preserve high concurrency
Parameters of a locking protocol?

18. Locking Protocol: Parameters
What “modes” of locks to provide? Compatibility?
e.g., S for shared, X for exclusive
How to “well-behave” to obtain and hold locks?
in what sequence?
how long to hold?
What “units” to lock?
database? table? tuple? what else?
other units: attributes, range of attribute values (e.g., GPA > 3.0), predicate locking

19. Lock modes and compatibility
Shared lock = read lock= S
multiple transactions hold a shared lock over a data item.
Exclusive lock = write lock = X
at most one transaction holds an exclusive lock over a data item.
Lock manager gives locks based on compatibility matrix: X S N Y

20. Motivation: a “simple” protocol
Lock modes:
S for shared and X for exclusive access
compatibility: (S, S) = T, otherwise F
Behavior:
lock (the maximum mode) before access
release lock immediately after
Unit:
a relation

21. Simple Protocol: what’s wrong?
Xact T Xact T2
X.lock(A’s relation)
read(A)
A = A + 1
write(A)
X.release-lock(A’s relation)
read (A)
A = A * 2
write (A)
X.lock(B’s relation)
read(B)
B = B * 2
write(B)
X. release-lock(B’s relation)
B = B + 1
X.release-lock(B’s relation)
fail to interleave dependencies in the right order

22. Solution: 2 Phase Locking (2PL)
Each transaction has two phases:
Getting locks (growing)
acquire lock of the required mode (S or X)
can only lock data items during this phase.
may also upgrade the locks (from S-lock to X-lock).
read/ write the locked data items.
no release-lock in this phase
Releasing locks (shrinking)
can only release locks on the data items.
may also downgrade the locks (from X-lock to S-lock).
the phase starts with the first release-lock.
no locking after the first release-lock.
Rule: Transactions do not get any new lock after giving up one.

23. Simple protocol versus 2PL protocol
Xact T Xact T2
X.lock(A)
read(A)
A = A + 1
write(A)
X.release-lock(A)
read (A)
A = A * 2
write (A)
X.lock(B)
read(B)
B = B * 2
write(B)
X.release-lock(B)
B = B + 1
Xact T1 Xact T2
S.lock(A)
read(A)
A = A + 1
X.lock(A)
write(A)
S.lock(B)
read(B)
B = B + 1
X.lock(B)
write(B)
X.release-lock(A)
X.release-lock(B)
read (A)
A = A * 2
write (A)
B = B * 2
write(B) X. release-lock(A)
X. release-lock(B)
2PL is serializable

24. Transaction interleaving in 2PL schedules
Xact T1 Xact T2
S.lock(A)
read(A)
A = A + 1
X.lock(A)
write(A)
S.lock(B)
read(B)
B = B + 1
X.lock(B)
X.release-lock(A)
read (A)
A = A * 2
write (A)
write(B)
X.release-lock(B)
B = B * 2
X. release-lock(A)
X. release-lock(B)
2PL schedules are not generally serial.

25. Why 2PL schedule is serializable?
Locks of conflicting operations are not compatible.
2PL does not allow the swap of conflicting operations.
serial order between conflicting operations
all conflicting operations of T1 before T2.
It is possible to swap non-conflicting operations.
provides concurrency

26. Locking Protocol: Granularity?
Unit of locking: How to increase concurrency?
coarse units? fine units?
Granularity:
concurrency vs. overhead
hierarchical lockable units:
Database, relations/ files, pages, tuples, attributes
Correctness problem:
T1 S.locks a tuple, T2 X.locks the file?
Solution: create a collision path, so that different units would collide if they should

27. Granularity Locking Example
Transaction T1 writes on a tuple in Student => X lock on tuple
Transaction T2 wants to scan the whole DB => S lock on DB, allowed??
T1 has to implicitly notify other transactions
puts “intentions locks” on the tuple’s parents in the lockable units hierarchy
T1: I
T2: Grant S? DB
T1: I
Relation Student
Relation Enrollment
T1: X
Tuple
Tuple
Tuple
Tuple

28. Granularity Locking Example, contd.
T1 reads some tuples from Student => S on tuple, I on its parents
T2 wants to scan the whole DB => S lock on DB, allowed??
We need different types of intention locks to increase concurrency
IS and IX
also SIX (intension to upgrade), why is it useful?
T1: IS
T2: Grant S? DB
T1: IS
Relation Student
Relation Enrollment
T1: S
Tuple
Tuple
Tuple
Tuple
SIX: good for complete scan + occasional update. Without SIX, have to do S then IX separately (high locking overhead), or use an X (too strong).

29. Lock Compatibility TableX
SIX IX S IS NL
privilege ordering

30. Compatibility Example
SIX
Grant S? IS? IX? DB
Questions:
(SIX, S) = No? (SIX, IS) = Yes? (SIX, IX) = No?
SIX
SIX
Relation Student
Relation Enrollment X X
Tuple
Tuple
Tuple
Tuple

31. Granularity Locking Database: as hierarchy of lockable units
Locking: to lock a unit,
first lock all containing units with “intension”
intension locks: IS, IX, SIX (intension to upgrade)
Unlocking:
release all relevant locks at once, or leaf to root
why this order?
DAG generalization: can’t do the other way around, since X not compatible with X (and they may take different path).

32. Granularity Locking: DAG
Generalization: DAG of units:
S locks at least one path to the node
X locks all paths to the node
DAG generalization: can’t do the other way around, since X not compatible with X (and they may take different path).
Q: Why implicit S if one parent is X (or S, SIX)?
A: Since that parent is in X maybe for other nodes, and not this one; otherwise all parent will be in X, in which case this node will be implicitly in X.

33. How “long” to hold a lock?
2PL requirement:
only “shrink” after “growing”
End of transaction:
unlock (to make data accessible) at xact commit
called strict 2PL
why?

34. Problem with non-strict 2PL
Cascading rollback we should never have let T1 commit T1 T2
write(B)
read(A)
commit
read(A)
write(A)
T2 Aborts

35. Additional issues Deadlock? Optimistic concurrency control
Assume rare unserializable behavior
Timestamping followed by validation