1. Adapted from slides by J. Gray & A. Reuter
Isolation Concepts
Chapter 7 in Gray and Reuter
11/23/2018
Adapted from slides by J. Gray & A. Reuter

2. Why Lock?
Give each transaction the illusion that there are no concurrent updates
Hide concurrency anomalies.
Do it automatically
Goal:
Although there is concurrency in system execution is equivalent to some serial execution of the system
Not deterministic outcome, just a consistent transformation
ECE 569

3. The Essentials Notation Definition
Every transaction T has a Read Set denoted: R(T) and a Write Set denoted: W(T)
Definition
T1 and T2 conflict IFF W(T2)  (R(T1)  W(T1)) ¹ Ø ; or
W(T1)  (R(T2)  W(T2)) ¹ Ø
If they conflict, delay one until the other finishes
ECE 569

4. Laws Of Concurrency Control
First Law of Concurrency Control Concurrent execution should not cause application programs to malfunction.
Second Law of Concurrency Control Concurrent execution should not have lower throughput or much higher response times than serial execution.
ECE 569

5. Transactions and Serializability
Database modeled as a set of elements representing relations, pages, tuples or whatever.
Transactions are sets of operations which access these elements
{r[x] | w[x]}* {c | a}
A concurrent execution of several transactions is serializable if it is equivalent to a serial execution of the same transactions
Two histories are equivalent if all transactions read the same values in both histories and the final states of the database are identical
11/23/2018
ECE 569

6. Why Serialization? T1: r1[x] w1[x] c1 T2: r2[x] a2
deposit(item x, int amt) {
t = read(x);
write(x, t + amt);
commit(); }
T1: r1[x] w1[x] c1
transfer(item x, item y, int amt)
f = read(x);
if (f < amt)
abort()
else
write(x, f-amt);
t = read(y);
write(y, t+amt);
T2: r2[x] a2
T2’: r2[x] w2[x] r2[y] w2[y] c2
11/23/2018
ECE 569

7. Why Serialization? 1. Lost updates - Deposit made by T1 is lost
T1: r1[x] w1[x] c1
T2: r2[x] w2[x] r2[y] w2[y] c2
2.Dirty Reads- Amount deducted from x by T2 disappears
T1: r1[x] w1[x] c1
T2: r2[x] w2[x] A2
11/23/2018
ECE 569

8. Why Serialization?
Incorrect Summary - (Similar to unrepeatable read problem)
print_sum(item x, item y) {
f = read(x);
g = read(y);
printf("%d\n", f+g);
commit(); }
T2: r2[x] w2[x] r2[y] w2[y] c2
T3: r3[x] r3[y] c3
Sum is “short” by amount being transferred.
11/23/2018
ECE 569

9. Serializability Theory - Chapter 2 Bernstein
Transactions
Definition- A transaction Ti is a partial order with ordering relation <i where:
1. Ti  {ri[x], wi[x] | x is a data item}  {ai, ci}; and
2. ai  Ti iff ci  Ti; and
3. If t is ci or ai, then for any other operation p  Ti, p <i t; and
4. If ri[x]  Ti and wi[x]  Ti, then either ri[x] <i wi[x] or wi[x] <i ri[x].
11/23/2018
ECE 569

10. Transactions A transaction is a partial order (i, <i)
i is the set of operations
<i is the “happened-before” relation for operations in i.
11/23/2018
ECE 569

11. Histories Histories are used to model concurrent executions
Definition- Let T = {T1, T2, ..., Tn} be a set of transactions. A complete history H over T is a partial order with ordering relation <H where:
1. H = ;
2. <H
3. For any two conflicting operations p, q  H, p  q, either p <H q or q <H p.
11/23/2018
ECE 569

12. Histories Example- A history H over T = {T1, T2} Summary
H contains all of the operations in T
<H honors all of the orderings of the transactions {T1, T2, ..., Tn}.
All conflicting operations are ordered.
11/23/2018
ECE 569

13. History Prefixes
Definition- A history H’ = (H’, <H’) is a prefix of a history H = (H, <H) if:
1. H’  H; and
2. p, q  H’, p <H’ q iff p <H q; and
3. p  H’, q  H, q <H p  q  H’
Example- A prefix H’ of H above.
11/23/2018
ECE 569

14. Serializability
Definition- The committed projection of a history H, C(H), is the history obtained by removing all operations of transactions that are not committed from H.
Example- C(H’)
11/23/2018
ECE 569

15. Serializability Example- Serial histories over T = {T1, T2} 11/23/2018
ECE 569

16. Conflict Serializability
Definition- Two histories H and H’ are conflict equivalent () if:
1. They are defined over the same set of transactions and have the same set of operations; and
2. For all conflicting operations pi and qj such that ai, aj  H (or H’),
pi <H qj iff pi <H’ qj
Definition- A history is conflict serializable if C(H) is conflict equivalent to some serial history Hs.
11/23/2018
ECE 569

17. Conflict Serializability
Example- History H is not conflict serializable because
w1[x] <H w2[x] rules out equivalence with T2T1
w2[y] <H r1[y] rules out equivalence with T1T2
11/23/2018
ECE 569

18. Conflict Serializability
Example- History H’ is conflict serializable. It is equivalent to T1T2.
11/23/2018
ECE 569

19. Serializability Theorem
Definition- The serialization graph of a history H, SG(H), is a directed graph with nodes corresponding to committed transactions in H and includes all edges Ti  Tj such that pi <H qj and pi conflicts with qj.
Examples-
1. SG(H)
11/23/2018
ECE 569

20. Serializability Theorem
2. SG(H’)
3. SG(H1)
H1 = r1[x] w2[x] c2 w1[y] c1 r3[x] w3[y] c3
11/23/2018
ECE 569

21. Serializability Theorem
Serializability Theorem- A history H is conflict serializable iff SG(H) is acyclic.
Proof
1. If SG(H) is acyclic then H is conflict serializable.
a) Assume SG(H) is acyclic (we will show H is CSR)
b) Let Hs be a serial history including all committed transactions in H.
c) Order transactions in Hs such that if Ti  Tj then Ti precedes Tj in Hs, i.e., order of transactions in Hs is a topological sort of SG(H). (SG(H) is acyclic)
11/23/2018
ECE 569

22. Serializability Theorem (Proof Cont.)
d) C(H)  Hs
Let pi and qj be conflicting operations from distinct transactions in C(H) such that pi <H qj
Ti and Tj are committed (in C(H)), so they must be included in SG(H)
There must be an edge Ti  Tj in SG(H) because pi and qj conflict and pi <H qj.
Our construction ensures that Ti precedes Tj in H, and thus, pi <Hs qj
11/23/2018
ECE 569

23. Serializability Theorem (Proof Cont.)
2. If H is conflict serializable then SG(H) is acyclic.
a) Assume H is conflict serializable (we will show SG(H) is acyclic)
b) Let Hs be a serial history such that C(H)  Hs (There must be one because H is conflict serializable.)
c) Ti  Tj in SG(H) implies Ti <Hs Tj
Because Ti  Tj in SG(H) there must be conflicting operations pi and qj in C(H) where pi <H qj
Since C(H)  Hs, we know that pi <Hs qj and therefore Ti <Hs Tj
11/23/2018
ECE 569

24. Serializability Theorem (Proof Cont.)
d) SG(H) is acyclic
Assume for the sake of a contradiction that there is a cycle T1  T2  ...  Tn  T1 in SG(H)
From argument in (c) this implies T1 <Hs T2 <Hs ... <Hs Tn <Hs T1
By transitivity we get T1 <Hs T1 which is clearly impossible
11/23/2018
ECE 569

25. Properties of Histories
Definition- Transaction Ti reads-x-from Tj in H if:
1. wj[x] <H ri[x]; and
2. Aj <H ri[x]; and
3. wk[x]  H, wj[x] <H wk[x] <H ri[x] implies ak <H ri[x].
Example-
H = w1[x] w2[y] r1[y] w2[x] a2 r1[x]
T1 reads-y-from T2
T1 reads-x-from T1
11/23/2018
ECE 569

26. Properties of Histories
Definition- A history H is recoverable (RC) if Ti reads- from Tj (i  j) and ci  H implies cj <H ci
Example- H = r1[x] w2[y] w2[x] r3[x] w1[y] c1 w3[y] c3 c2
T3 reads-x-from T2 but c2 does not precede c3 in H, thus H is not RC.
Definition- A history H avoids cascading aborts (ACA) if Ti reads-x-from Tj (i  j) implies cj <H ri[x]
Definition- A history H is strict (ST) if wi[x] <H oj[x] (i  j) implies either:
ai <H oj; or
ci <H oj.
11/23/2018
ECE 569

27. concepts
What are the three problems non-serializable histories have? What dependencies are concerned?
Define a history being conflict serializable
What is the serialization graph of a history?
What is the serializability theorem?
What is a recoverable history? A history that avoids cascading aborts? Strict history?
11/23/2018
ECE 569

28. View Serializability
Definition of serializability based on the view transactions have of the database
Definition- A write wi[x] is the final write of x in H if:
wi[x]  H; and
ai  H; and
wj[x]  H (i ≠ j), wj[x] <H wi[x] or aj  H
11/23/2018
ECE 569

29. View Serializability (Cont.)
Definition- Two histories H and H’ are view equivalent if:
1. They are over the same transactions and have the same operations; and
2. For all Ti and Tj not aborted in H, Ti reads-x-from Tj in H iff Ti reads-x-from Tj in H’; and
3. wi[x] is the final write of x in H iff wi[x] is the final write of x in H’.
Definition- A history H is view serializable if for every prefix H’ of H, C(H’) is view equivalent to a serial schedule
11/23/2018
ECE 569

30. View Serializability (Cont.)
Example-
H = r1[x] w2[y] w2[x] c2 r3[x] w1[y] c1 w3[y] c3
1. H1’ = r1[x] w2[y] w2[x] c2
C(H1’) = w2[y] w2[x] c2
C(H1’) is view equivalent to a serial history (itself)
2. H2’ = r1[x] w2[y] w2[x] c2 r3[x] w1[y] c1
C(H2’) = r1[x] w2[y] w2[x] c2 w1[y] c1
C(H2’) is not view equivalent to T1T2 (w1[y] not w2[y] is final write of y in H)
C(H2’) is not view equivalent to T2T1
11/23/2018
ECE 569

31. View Serializability (Cont.)
Example-
H = r1[x] w2[y] w2[x] r3[x] w1[y] c1 w3[y] c3 c2
2. H2’ = r1[x] w2[y] w2[x] r3[x] w1[y] c1 w3[y] c3
C(H2’) = r1[x] r3[x] w1[y] c1 w3[y] c3
C(H2’) is view equivalent to T1T3
T3 writes final version of y in both histories
3. H3’ = r1[x] w2[y] w2[x] r3[x] w1[y] c1 w3[y] c3 c2
C(H3’) = r1[x] w2[y] w2[x] r3[x] w1[y] c1 w3[y] c3 c2
C(H3’) is view equivalent to T1T2T3
T3 reads-x-from T2 in both histories.
T2 writes final (only) version of x in both histories
11/23/2018
ECE 569

32. Two-Phase Locking (2PL)
Notation
rli[x] - A read lock for element x granted to transaction Ti
wli[x] - A write lock for x granted to Ti
rui[x] - Release a read lock for x held by transaction Ti
wui[x] - Release a write lock for x held by Ti
11/23/2018
ECE 569

33. Basic 2PL
Protoco
1. Before executing pi[x], a lock pli[x] must be acquired on Ti’s behalf. If another transaction Tj is holding a lock qlj[x] that conflicts with pli[x] then the operation is delayed until the lock can be set. (well-formed)
2. The scheduler cannot release the lock pli[x] at least until the completion of pi[x] has been acknowledged.
3. A transaction cannot acquire any new locks after it has released a lock.
11/23/2018
ECE 569

34. Basic 2PL
11/23/2018
ECE 569

35. Correctness of 2PL Characteristics of 2PL Histories
1. If oi[x]  C(H) then
a) oli[x]  C(H) and oli[x] <H oi[x]; and
b) oui[x]  C(H) implies oi[x] <H oui[x]
2. If pi[x] and qj[x] (i  j) are conflicting operations on x in C(H), then either:
a) pui[x] <H qlj[x]; or
b) quj[x] <H pli[x]
3. If pi[x] and qi[y] are in C(H), then pli[x] <H qui[y]
11/23/2018
ECE 569

36. 2PL ??? CSR 2PL histories are a subset of CSR histories
r1[A] w1[A] r2[A] w3[A] c3 r1[B] w1[B] c1 r2[B] c2
11/23/2018
ECE 569

37. Correctness of 2PL (Cont.)
Theorem- Every 2PL history is CSR
Proof
I. Ti  Tj  SG(H) implies there is an element x for which pui[x] <H qlj[x]
a) The edge Ti  Tj  SG(H) implies that pi <H qj.
b) By 2 above, we know that pui[x] <H qlj[x] or quj[x] <H pli[x]
c) Assume quj[x] <H pli[x]. By 1(a), 1(b) and transititivity, we get qj <H pi. But this contradicts I(a).
11/23/2018
ECE 569

38. Correctness of 2PL (Cont.)
II. If T1  T2  ...  Tk is a path in SG(H) then pu1[x] <H qlk[y] for some x and y.
a) Basis: T1  Tk  SG(H)
pu1[x] <H qlk[x] holds by argument in I.
b) Induction Step: Assume that hypothesis holds for path T1  T2   Tk. Now consider path T1  T2  ...  Tk  Tk+1.
qlk[z] <H puk[y] follows from 3 above.
Becuase Tk  Tk+1  SG(H), from I we know there is a y, puk[y] <H qlk+1[y]
Thus, qlk[z] <H qlk+1[y]. Combining this with induction hypothesis (pu1[x] <H qlk[z]), we get pu1[x] <H qlk[y]
11/23/2018
ECE 569

39. Correctness of 2PL (Cont.)
III. Assume that SG(H) contains a cycle T1  T2  ...  Tn  T1. From II, this implies pu1[x] <H ql1[y]. But this contradicts the two-phase rule (3). Must assume that 2PL schedules are CSR.
11/23/2018
ECE 569

40. Deadlock T1: T2: l1(A) l2(B) r1(A) r2(B)
l1(B) // T1 waits l2(A) // T2 waits
11/23/2018
ECE 569

41. Other Variations Conservative 2PL Strict 2PL (Rigorous 2PL)
When a transaction starts, it predeclares the set of elements it will read and write
A transaction must acquire all of its locks before it executes any operations. If all locks cannot be acquired, any acquired locks are released.
Deadlock is avoided because no locks are held while requesting other locks.
Strict 2PL (Rigorous 2PL)
Release all locks only after transaction commits
Rigorous histories ensure that serialization order is compatible with commit order.
Which avoids cascading rollback?
11/23/2018
ECE 569

42. 11/23/2018
ECE 569

43. Serializability Requirements
Lock everything transaction accesses
Do not lock after unlock.
Backout may have to undo a unlock (= lock).
So do not release locks prior to commit
ECE 569

44. Degrees of Isolation
SQL allows client to trade-off isolation against performance by specifying a degree of isolation.
0° - Does not overwrite another transaction’s dirty data if the other transaction is 1° or better.
transaction gets short xlocks for writes (well formed writes not 2Ø, no read locks)
1° - No lost updates
transaction gets no read locks (well formed and 2Ø writes,)
2° - No lost updates or dirty reads
transaction releases read locks right after read (well formed with respect to reads but not 2Ø with respect to reads)
3° - No lost updates and repeatable reads (implies serializability)
well formed and 2Ø
ECE 569

45. Isolation Levels Theorem
What is effect of some transactions employing an isolation level lower than 3°?
If others lock 1° or better and I obey 0°, 1°, 2° or 3° any legal history will give me 1°, 2° or 3° isolation.
But the DB may be corrupted!
Must ensure that if I allow dirty reads, I can still produce consistent updates.
ECE 569

46. Comparison of Isolation Levels
Issue
Degree 0
Degree 1
Degree 2
Degree 3
Common name
Chaos
Isolated
Serializable
Repeatable reads
Browse
read uncommited
Cursor stability
read committed
Protection
Provided
Lets others run
at higher
isolation
0 and
no lost updates 1+
No dirty reads
2 +
Repeatable
reads
Rollback supported
Committed data
Writes visible
immediately
Writes visible at
eot
Same
Dirty data
You don't
overwrite dirty
data
0 and others do
not overwrite
your dirty data
0, 1, and you
don't read dirty
0,1,2 and others
don't produce dirty
data you read
Lock protocol
Set short
Set long
1 and set short
1 and set long
exclusive locks
on data you
write
share locks on
data you read
Trans structure
Well-formed
Wrt writes
wrt
writes
Two-phase
And
and
Concurrency
Greatest:
only set short
write locks
Great:
only wait for
Medium:
hold few read
locks
Lowest:
any data
touched
Locked to
eot
ECE 569

47. Comparison of Isolation Levels
W  W
W  R
R  W
None
Dependencies
same
Same
Apply log in 1°
order
Dangerous, Updates may be lost and violate 3°
System Recovery
Can Undo incomplete transactions
UNDO may cascade
Cant rollback
Rollback
Most:
Set long R&W
Medium:
Set R&W but short R
Small:
Only write locks
Least:
short W locks
Overhead
Degree 3
Degree 2
Degree 1
Degree 0
Issue
ECE 569

48. The Phantom Problem Phantom Records (if the locks are for each record)
If I try to read hair = "red" and eyes = "blue" and get not found, what gets locked? No records have been accessed so no records get locked
If I delete a record, what gets locked? (the record is gone)
Predicate Locks can solve this problem
Page Locks (done right) can also solve this problem
lock the red hair page and the blue eye page,
prevents others red hair and blue eye inserts & updates
High volume TP systems use esoteric locking mechanisms:
Key Range Locks to protect b-trees
Hole Locks to protect space for uncommitted deletes
ECE 569

49. Predicate Locks
Read and write sets can be defined by predicates (e.g. Where clauses in SQL statements)
When a transaction accesses a set for the first time,
Automatically capture the predicate
Do set intersection with predicates of others.
Delay this transaction if conflict with others.
Problems with predicate locks:
Set intersection = predicate satisfiability is NP complete (slow).
Hard to capture predicates
Pessimistic: Jim locks eye = blue Andreas locks hair=red
Predicate says conflict, but DB may not have blue eyed red haired person.
ECE 569

50. Granular Locks Idea Pick a fixed set of predicates
They form a lattice under and, or
This can be represented as a graph
Lock the nodes in this graph
Example
Can lock whole DB, whole file, or just one key value.
Size of lock is called granule.
ECE 569

51. Lock Granularity Compatibility Matrix Mode I ntent S hare e X clusive
Batch wants to lock whole DB
Interactive wants to lock records
How can we allow both granularities?
Intention mode locks on coarse granules
Compatibility Matrix
Mode I
ntent S
hare e X
clusive + -
ECE 569

52. Lock Granularity: refined intent modes
Intent mode locks say locks being set at finer granularity
If only reading at finer granularity then I compatible with S.
Introduce IS: intend to set fine S locks
IX: intend to set fine S or X locks
SIX: S + IX
Compatibility Matrix IS IX S
SIX X + -
ECE 569

53. Granularity Example T1 T2 T3 Rules for a granularity tree
has record locks in file 1 and file 2. T2
all of file 3 locked shared mode
most of file 2 locked shared (fine granularity) T3
waiting
DATABASE
FILE FILE FILE-3
KEY-A
T1:IX, T2:IS
T3:S
T1:X
T1:S, T2:S
T1:IX
T2:S
T2:IS
T1:S
Rules for a granularity tree
Lock root to leaf
If set X,S below get IX or IS above
Rules for a DAG (Directed Acyclic Graph)
Get ONE IS,IS,...,S path for reads
Get ALL IX,IX,...,X paths for a write
ECE 569

54. Update Mode Locks Most common form of deadlock
T1 READ A (lock A shared)
T2 READ A (lock A shared)
T1 UPDATE A (lock A exclusive, wait for T2)
T2 UPDATE A (deadlock A exclusive, wait for T1)
Introduce update mode lock
Compatibility Matrix IS IX S
SIX U X + -
U compatible with S so updaters do not hurt readers.
S is not compatible with U - makes other readers wait.
ECE 569

55. Lock Conversion
If requested lock already held in one mode, new mode is: max (old, requested) X
SIX U IX S IS
ECE 569

56. Key Range Locking (for Phantoms)
Operations
Read unique(x) /* return value associated with key x */
Read next(x) /* return value associated with first key value following x */
Insert(x, v); /* associate value v with key value x */
Delete(x) /* delete value associated with key value x */
Insert between X and Y
must test to see that no one else cares that [X,Y] was empty, but is now full, i.e., no other concurrent trans did a Read Next("X");).
ECE 569

57. Key Range Locking (static ranges)
Static Ranges - [A,B), [B,C),...., [Z,¥)
Insert(x, v) and Delete(x) must get exclusive lock on range x falls in.
Read(x) gets shared lock on range x falls in
Read Next(x) gets shared lock on all key ranges between that of x and the range of the next key value (the value returned).
Lock first element in range as surrogate for the range.
Must get any necessary intention locks as well.
ECE 569

58. Key Range Locking (dynamic ranges)
Use actual key values in relation to construct key ranges.
Insertions and deletions will change the set of ranges.
Example - Relation contains A, C, T, W, X.
Ranges are [A, C), [C, T), [T, W), [W, X), [X, )
Insertion of U, will split range [T, W) into [T, U) and [U, W).
Locking Protocol
Read unique(x)
If found need to protect it from deletion (how?)
If not found need to protect against its later insertion (how?)
Read next(x)
Assume that transaction holds lock on x already and the next key value is y.
Need to protect against an insertion between x and y (how?)
Need to protect y against deletion (wait until we consider delete)
11/23/2018
ECE 569

59. Key Range Locking (dynamic ranges)
Insert(x)
Assume that F is being inserted into A, C, T, W, X.
Will transform [C, T) to [C, F) and [F, T).
Get exclusive lock on [C, T) to ensure that no other transaction has it locked.
Get exclusive lock on [F, T). Can now drop lock on [C, T) but hold lock on [F, T) until commit. (Why??)
Delete(x)
Assume that F is being deleted from A, C, F, T, W, X
Will merge [C, F) and [F, T) into [C, T).
Get exclusive lock on [F, T) and then one on [C, F). Why is this order necessary?
When can these locks be released?
Comments
After lock wait may need to revalidate the key range to make sure it has not changed in the mean time.
How do we know this protocol ensures isolation?
11/23/2018
ECE 569

60. DAG Locking
In general predicate locks and key-range locks form a DAG not just a tree
a lock can have many parents.
Blue-eye key range
Blonde-hair key range.
Hierarchical locks work for this.
Read locks any path
Writes lock all paths.
Hair Index
Auburn
Black
Blonde
Brunette
Platinum
Red
White
Yellow
Eye Index
Blue
Brown
Green
Gray
Famous People
T : IX, T' : IX
T : IX
T’ : IX
T : X
T' : S
Hair
Red Hair
Blue Eyes
Don
Marilyn
Monroe
ECE 569

61. Discussion
How can we avoid phantom problem in project if we do page locking?
Which pages must be locked (until end of transaction)?
Data dictionary pages?
Hash bucket pages?
Pages in relation? Which ones?
How can we avoid phantoms with tuple level locking?
Relations with an index?
Those without an index?
11/23/2018
ECE 569

62. Phantom Solutions for Hash Index
How can we synchronize search in hash file?
1. Lock header block. Get exclusive lock for insertion or deletion, shared locks for searching.
This solution suffers from low concurrency
2. Acquire shared or exclusive locks on hash bucket.
This solution is much better.
11/23/2018
ECE 569

63. Phantom Solutions for Hash Indexes
3. An Intention Locking Approach
Search for key K
Acquire a shared semaphore on appropriate hash bucket.
Acquire a shared lock on K’ where K’ is largest key in hash bucket less than or equal to K.
Release semaphore.
Insertion
Get exclusive semaphore on appropriate hash bucket.
Acquire an ix lock on K’ where K’ is largest key in hash bucket less than or equal to K.
Acquire an exclusive lock on K.
Release intention lock.
11/23/2018
ECE 569

64. An Intention Locking Approach
Deletion
Get exclusive semaphore on appropriate hash bucket.
Get an ix lock on K.
Release semaphore.
Discussion of approach 3.
Is concurrency better than approach 2?
Does it solve the phantom problem?
Can the protocol be improved (i.e., fewer or less restrictive locks)?
11/23/2018
ECE 569

65. B-tree synchronization
When searching for the key value down the path, first acquire shared-lock on the root, then go down one level, and acquire shared-lock on that index node, then release the lock on the root page
Locking on the leave page is more interesting
11/23/2018
ECE 569

66. B-tree synchronization (cont’d)
Exact-match query: search for all the tuples with key value c
Acquire the shared lock on the range [c, c_next) where c_next is the next key value higher than c
Range query [c1,c2]
Acquire the shared locks on the range [c1, w), [w, x), [x, y), …., [z, c2), [c2, n_next)
Insert c
Acquire the ix lock on the range [c1, c2) where c1 <= c <= c2
Insert, [c1,c2) will be split into [c1,c) and [c, c2)
Acquire exclusive lock on [c, c2)
11/23/2018
ECE 569

67. Locking API lock(name, - name of resource mode, - S, X, SIX, IX, IS, U
duration - instant, short, long
wait) - no, timeout, yes
unlock(name, - name of resource
clear) - decrement count to zero or not.
Locks must count
if lock twice and unlock once, lock kept
11/23/2018
ECE 569

68. Requirements Lock and unlock operations must be atomic
Lock manager must be fast for common case (i.e., lock can be acquired immediately)
Must keep lock table small
Lock table must allow high concurrency
11/23/2018
ECE 569

69. Approach Lock table implemented as hash table
Hash on the lock name
One mutex per hash chain
Locks not held by any transaction are removed from lock table.
Use efficient methods to allocate and deallocate lock table entries
Pool of preallocated lock table entries
These operations will be common because lock conflicts are rare.
11/23/2018
ECE 569

70. Lock Table Implementation
11/23/2018
ECE 569

71. Lock Table Implementation
LOCK NAME
HASH LINK
SEMAPHORE
MODE
WAITS?
QUEUE
HEADER
FROM
HASH
TABLE
NEXT IN
HASH CHAIN
NEXT IN QUEUE
MODE HELD
MODE DESIRED
GRANTED?
DURATION
COUNT
TRANSACTION
GRANTED GROUP
WAITING GROUP
list of locks
of transaction
T (from Trans
control block)
next lock of T
ECE 569

72. LOCK Control Flow Hash name & Search lock table
Not Found (lock is free)
Construct lock header and lock request
Add to lock table and exit
Lock Already Granted To Requestor?
Yes (conversion case)
Requested Mode Compatible With Other Granted requests?
Yes
Grant, Increment Count, Exit No
Increment Count, Set convert mode, Wait
No (new request case)
Allocate lock request and insert at end of queue.
Anyone Waiting?
Mark lock request waiting, Wait
Compatible With Grantees?
Yes - Then Grant
No - Wait
Exit
ECE 569

73. UNLOCK Control Flow Hash Name & Search lock table
Find lock request In Queue
Decrement Count
If Count > 0 then
Exit - lock remains held
Remove lock request from queue
If Queue Empty then
Deallocate Lock Header and exit
For Each Waiting Conversion
If Compatible With Granted Group then
Mark lock request granted & Wakeup
If No Conversions Waiting Then
For Each Waiter (in FIFO order)
If Compatible With Granted then
Mark Lock Request granted & Wakeup
Else
Exit
ECE 569

74. Blocking Transactions
One approach
Transaction must be blocked if conflicting lock is held by another transaction.
Assume that a lock request contains a condition variable. To block transaction, do a wait on condition variable.
Before blocking transaction, register a “wakeup call”. Alarm thread wakes up occasionally and unblocks threads that have registered “wakeups”.
When a lock is released, pick one of the pending requests, grant lock and unblock waiting thread (i.e., signal condition variable in lock request).
11/23/2018
ECE 569

75. Blocking Transactions (Cont.)
When a transaction becomes unblocked, it must check to see if the lock was granted. If not, remove lock request node and return lock_timeout response.
When a transaction receives a lock_timeout response, it must “clean up” and then return a error response to the client. Clean up includes:
Free allocated memory
Unfix buffers
11/23/2018
ECE 569

76. Locking Performance
Goal- Predict the effect of various design decisions on throughput and response time of transactions
Assumptions
Data items are accessed with uniform probability
All locks are exclusive
Strict 2PL
Performance objective-
Provide maximum throughput, while keeping response time below t seconds for 90% of all transactions (TPC Benchmark)
11/23/2018
ECE 569

77. Data Contention and Thrashing
Resource Contention
Resources- memory, CPU time, or I/O channels
When resources become overcommitted, system becomes less productive using more resources on unproductive work, e.g., page faults.
Data Contention
Transactions contend for locks causing:
Blocking
Restarts (deadlock)
11/23/2018
ECE 569

78. Data Contention and Throughput
Thrashing
throughput The rate at which transactions complete
MPL The number of active transactions
Initially, increasing the MPL increases throughput.
At the point of thrashing, further increases in MPL reduce throughput.
11/23/2018
ECE 569

79. Data Contention Thrashing
DC-Thrashing
Blocking is main cause of DC-Thrashing
Restart rate is low at onset of thrashing (1-2%)
After onset of DC-Thrashing, adding one transaction blocks more than one transaction
Very little blocking is necessary to cause DC-Thrashing. At onset:
Average length of lock queues can be less than one
Most deadlock cycles will have only two transactions
If half the transactions are blocked, there is a good chance of DC- Thrashing.
11/23/2018
ECE 569

80. A Simple Model for Blocking
Based on Section of text.
Definitions
N MPL of the system
k Number of locks acquired by each transaction
D The number of data elements in the database
Blocking probability
Each transaction holds approximately k/2 locks.
At any given time, the number of locks held by other transactions is
11/23/2018
ECE 569

81. A Simple Model for Blocking
The probability a request is blocked is:
PW = 
The probability a transaction is blocked is:
DC-Workload
Defined as
DC-Thrashing begins roughly when PW(T) = .75
11/23/2018
ECE 569

82. Deadlock Probability of Deadlock
Cycle of length 2 - Transactions T1 and T2
Probability that T1 waits for some transaction is PW(T). Call the transaction it waits for T2.
Probability that T2 waits for the transaction T1 is PW(T)/(N - 1), i.e., 1/(N - 1) times the probability it waits for some transaction
Probability a transaction participates in a cycle of length 2 is
Probability a transaction participates in a cycle of length 3 is proportional to PW(T)3
11/23/2018
ECE 569

83. Deadlock (Cont.)
For low probability of waiting, cycles of length 3 can be ignored.
Probability any transaction deadlocks is approximately
11/23/2018
ECE 569

84. Granularity The effect of granularity
The number of locks acquired by a transaction, k, is a function of D.
As D increases so does k until the granularity of an access matches that of the locks.
If a transaction accesses a few tuples in a large database, moving from page level granularity to tuple level granularity (D increases) will not increase k significantly.
To reduce granularity to the bit level will increase D and also increase k in the same proportion.
11/23/2018
ECE 569

85. Granularity (Cont.) Example: Assume that k = D in some region.
PW(T) = ((N - 1) 2 D)/2
Thus, as D increases (granularity is made finer) so does probability of waiting. (Throughput decreases)
Example: Assume that k = in some region.
PW(T) =
Thus, as D increases (granularity is made finer) probability of waiting decreases. (Throughput increases)
At some point, we may see a downturn in throughput for further increases in D due to increased resource contention.
11/23/2018
ECE 569