Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | denton-thornton |
View: | 27 times |
Download: | 1 times |
04/19/23 1
Isolation Concepts
Adapted from slides by J. Gray & A. Reuter
Chapter 7 in Gray and Reuter
04/19/23 ECE 569 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
04/19/23 ECE 569 3
The Essentials
Notation 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
04/19/23 ECE 569 4
Laws Of Concurrency Control
First Law of Concurrency ControlConcurrent execution should not cause application programs to malfunction.
Second Law of Concurrency ControlConcurrent execution should not have lower throughput or much higher response times than serial execution.
04/19/23 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
{ri[x] | wi[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
04/19/23 ECE 569 6
Why Serialization?
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);commit();
}}
T2: r2[x] a2
T2’: r2[x] w2[x] r2[y] w2[y] c2
04/19/23 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
04/19/23 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.
04/19/23 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].
04/19/23 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.
ri[x] wi[x]
ri[y]
ci
04/19/23 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.
n
iiT
1
n
ii
1;
04/19/23 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.
r1[x] w1[x]
r1[y]
c1
w2[x] w2[y] c2
04/19/23 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. r1[x] w1[x]
w2[x] w2[y] c2
04/19/23 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’)
w2[x] w2[y] c2
04/19/23 ECE 569 15
Serializability
Example- Serial histories over T = {T1, T2}
r1[x] w1[x]
r1[y]
c1 w2[x] w2[y] c2
r1[x] w1[x]
r1[y]
c1w2[x] w2[y] c2
T1T2
T2T1
04/19/23 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.
04/19/23 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
r1[x] w1[x]
r1[y]
c1
w2[x] w2[y] c2
04/19/23 ECE 569 18
Conflict Serializability
Example- History H’ is conflict serializable. It is equivalent to T1T2.
r1[y] w1[y]
r1[x]
c1
w2[x] w2[y] c2
04/19/23 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)
T1 T2
04/19/23 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
T1 T2
T1 T2
T3
04/19/23 ECE 569 22
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)
04/19/23 ECE 569 23
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
04/19/23 ECE 569 24
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
04/19/23 ECE 569 25
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
04/19/23 ECE 569 26
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
04/19/23 ECE 569 27
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.
04/19/23 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
04/19/23 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
04/19/23 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
04/19/23 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• T3 writes final version of y in both histories
04/19/23 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
04/19/23 ECE 569 33
Basic 2PL
Protocol
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.
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.
04/19/23 ECE 569 34
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]
04/19/23 ECE 569 35
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).
04/19/23 ECE 569 36
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]
04/19/23 ECE 569 37
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.
04/19/23 ECE 569 38
Other Variations
Conservative 2PL
1. When a transaction starts, it predeclares the set of elements it will read and write
2. A transaction must acquire all of its locks before it executes any operations. If all locks cannot be acquired, any acquired locks are released.
3. Deadlock is avoided because no locks are held while requesting other locks.
Strict 2PL (Rigorous 2PL)
1. Release all locks only after transaction commits.
2. Rigorous histories ensure that serialization order is compatible with commit order.
04/19/23 ECE 569 39
Distributed 2PL
Each resource manager carries out 2PL at its own site.
Must ensure that all sites agree on serialization order.
Example-T1A: w1A[x] c1A
SA
T2A:r2A[x] c2A
T1B: w1B[y] c1B
SB
T2B: r2B[y]c2B
04/19/23 ECE 569 40
Distributed 2PL
History is strict, 2PL and the commit order is same at both sites (c1 < c2). History is not globally serializable. T2 reads-x-from T1 at site SA and T1 reads-y-from T2 at site SB.
Because read lock in T2B is released before commit, commitment order at site SB does not match commit order.
04/19/23 ECE 569 41
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
04/19/23 ECE 569 42
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Ø
04/19/23 ECE 569 43
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.
04/19/23 ECE 569 44
Comparison of Isolation Levels
ProtectionProvided
Lets others runat higherisolation
0 and no lost updates
1+No dirty reads
2 +Repeatable
readsCommitted data Writes visible
immediatelyWrites visible at
eotSame Same
Dirty data You don'toverwrite dirty
data
0 and others donot overwrite
your dirty data
0, 1, and youdon't read dirty
data
0,1,2 and othersdon't dirty data
you readLock protocol Set short Set long 1 and set short 1 and set long
exclusive lockson data you
write
exclusive lockson data you
write
share locks ondata you read
share locks ondata you read
Trans structure Well-formedWrt writes
Well-formed wrtwrites
Two-phase wrtwrites
Well-formedAnd
Two-phase wrtwrites
Well-formed and
Two-phase
Concurrency Greatest: only set short write locks
Great: only wait for write locks
Medium: hold few read locks
Lowest: any datatouchedLocked to eot
Issue Degree 0 Degree 1 Degree 2 Degree 3Common name Chaos Isolated
SerializableRepeatable reads
Browseread uncommited
Cursor stabilityread committed
Rollback supported
04/19/23 ECE 569 45
Comparison of Isolation Levels
W WW RR W
W WW R
W WNoneDependencies
sameSameApply log in 1° order
Dangerous, Updates may be lost and violate 3°
System Recovery
SamesameCan 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 3Degree 2Degree 1Degree 0Issue
04/19/23 ECE 569 46
The Phantom Problem
Phantom Records 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
04/19/23 ECE 569 47
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.
04/19/23 ECE 569 48
Precision Locks: Lazy Predicate Locks
Method Check returned records against predicates on each
read/write
Example Andreas can't insert/read blue eyes Jim can't insert/read red hair. Evaluate predicates against records as they go by.
04/19/23 ECE 569 49
Granular Locks
DATABASE
FILE-1 FILE-2 FILE-3
KEY-A KEY-A KEY-A
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.
04/19/23 ECE 569 50
Lock Granularity
Batch wants to lock whole DB Interactive wants to lock recordsHow can we allow both granularities? Intention mode locks on coarse granules
Compatibility MatrixMode I ntent S hare e X clusive
I + - -S - + -X - - -
04/19/23 ECE 569 51
Compatibility MatrixIS IX S SIX X
IS + + + + -IX + + - - -S + - + - -
SIX + - - - -X - - - - -
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
04/19/23 ECE 569 52
Granularity Example
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
DATABASE
FILE-1 FILE-2 FILE-3
KEY-A KEY-A KEY-A
T1:IX, T2:IS T3:S
T1:X T1:S, T2:S
T1:IX T1:IX, T2:IS T2:S
T1:XT2:S
T1:IX T2:IS
T1:IX
T1:X
T3:S
T1:IX
T1:S
T2:IS
T2:S
T2:ST2:ST2:S
T2:S
T1 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
04/19/23 ECE 569 53
Update Mode Locks
Most common form of deadlockT1 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 lockCompatibility Matrix
IS IX S SIX U XIS + + + + - -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.
04/19/23 ECE 569 54
Lock Conversion
If requested lock already held in one mode, new mode is: max (old, requested)
X
SIX U
IX S
IS
04/19/23 ECE 569 55
Key Range Locking (for Phantoms)
OperationsRead 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");).
04/19/23 ECE 569 56
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.
04/19/23 ECE 569 57
Key Range Locking (dynamic ranges)
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 ProtocolRead 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)
04/19/23 ECE 569 58
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.
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?
04/19/23 ECE 569 59
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 IndexAuburn Black Blonde Brunette Platinum Red White Yellow
Eye Index Black Blue
Brown Green Gray Red
Famous People T : IX, T' : IXT : IX T’ : IX
T : XT' : S
Blonde Hair
Red Hair
Blue EyesDon
Marilyn
MonroeT : X
04/19/23 ECE 569 60
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?
04/19/23 ECE 569 61
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.
04/19/23 ECE 569 62
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.
• Release semaphore.
04/19/23 ECE 569 63
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)?
04/19/23 ECE 569 64
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
04/19/23 ECE 569 65
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
04/19/23 ECE 569 66
Approach
Lock table implemented as hash table
Hash on the lock name
One semaphore 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.
04/19/23 ECE 569 67
Lock Table Implementation
01
i
n
.
.
.
.
.
.
name: 10
mode: Xname: 25
mode: Sname: 80
mode: S
trid1
status: G
mode: X
cond. var.
trid2
status: W
mode: X
cond. var.
trid3
status: W
mode: R
cond. var.
trid2
status: G
mode: S
cond. var.
trid1
status: G
mode: S
cond. var.
trid2
status: G
mode: S
cond. var.
hash chain
lock queue lock queue lock queue
hash table
04/19/23 ECE 569 68
LOCK NAME HASH LINK SEMAPHORE MODE WAITS? QUEUE
HEADERFROM HASH TABLE NEXT IN
HASH CHAIN
NEXT IN QUEUE HEADER 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
Lock Table Implementation
04/19/23 ECE 569 69
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?
• Yes– Mark lock request waiting, Wait
• No– Compatible With Grantees?– Yes - Then Grant– No - Wait
Exit
04/19/23 ECE 569 70
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
Exit
04/19/23 ECE 569 71
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).
04/19/23 ECE 569 72
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
04/19/23 ECE 569 73
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)
04/19/23 ECE 569 74
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)
04/19/23 ECE 569 75
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.
04/19/23 ECE 569 76
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.
04/19/23 ECE 569 77
A Simple Model for Blocking
Based on Section 7.11.5 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
2
)1( kN
04/19/23 ECE 569 78
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
D
kN
2
)1(
D
kN
DPWk
PWk
kPW
kPW
k
PWTPW
k
k
2
)1(
)1 >> conflict, ofy probabilit Low(
2111
)1(1)(
2
2
)(22
TPWD
kNW
04/19/23 ECE 569 79
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
2
42
4
)1(
1
)(
D
kN
N
TPW
04/19/23 ECE 569 80
Deadlock (Cont.)
For low probability of waiting, cycles of length 3 can be ignored.
Probability any transaction deadlocks is approximately
1
)( 2
N
TPWN
04/19/23 ECE 569 81
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.
04/19/23 ECE 569 82
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.
D
N )1(
4 D