Professional Documents
Culture Documents
Lec24 6up
Lec24 6up
Lec24 6up
1
Example View Serializability – an Aside
• Alternative (weaker) notion of serializability.
• A schedule that is not conflict serializable: • Schedules S1 and S2 are view equivalent if:
– If Ti reads initial value of A in S1, then Ti also reads
initial value of A in S2
T1:
T1: R(A),
R(A), W(A),
W(A), R(B),
R(B), W(B)
W(B)
T2:
T2: R(A),
R(A), W(A),
W(A), R(B),
R(B), W(B)
W(B) – If Ti reads value of A written by Tj in S1, then Ti also
reads value of A written by Tj in S2
A – If Ti writes final value of A in S1, then Ti also writes
T1 T2 Dependency graph final value of A in S2
2
Non-2PL, A= 1000, B=2000, Output =? 2PL, A= 1000, B=2000, Output =?
Lock_X(A) Lock_X(A)
Read(A) Lock_S(A) Read(A) Lock_S(A)
A: = A-50 A: = A-50
Write(A) Write(A)
Unlock(A) Lock_X(B)
Read(A) Unlock(A)
Unlock(A) Read(A)
Lock_S(B) Lock_S(B)
Lock_X(B)
Read(B) Read(B)
Unlock(B) B := B +50
PRINT(A+B) Write(B)
Read(B) Unlock(B) Unlock(A)
B := B +50 Read(B)
Write(B) Unlock(B)
Unlock(B) PRINT(A+B)
Example: Output = ?
Lock_X(A)
Lock_S(B) Deadlocks
Read(B)
Lock_S(A)
• Deadlock: Cycle of transactions waiting for
Read(A)
A: = A-50
locks to be released by each other.
Write(A) • Two ways of dealing with deadlocks:
Lock_X(B)
– Deadlock prevention
– Deadlock detection
3
Deadlock Prevention Deadlock Detection
Database
Solution: New Lock Modes, Protocol
• Allow Xacts to lock at each level, but with a Database Multiple Granularity Lock Protocol Tables
special protocol using new “intention” locks: Tables Pages
• Still need S and X locks, but before locking an Pages • Each Xact starts from the root of the
hierarchy. Tuples
item, Xact must have proper intension locks
on all its ancestors in the granularity Tuples • To get S or IS lock on a node, must hold IS or
hierarchy. IS IX SIX S X IX on parent node.
– What if Xact holds SIX on parent? S on parent?
IS – Intent to get S lock(s) at IS √ √ - √ √
• To get X or IX or SIX on a node, must hold IX or
finer granularity. IX √ √ - - - SIX on parent node.
IX – Intent to get X lock(s) SIX √ - - - -
• Must release locks in bottom-up order.
at finer granularity. √ - - √ -
S
SIX mode: Like S & IX at Protocol is correct in that it is equivalent to directly setting
the same time. Why useful?
X - - - - - locks at the leaf levels of the hierarchy.
4
Dynamic Databases – The “Phantom”
Examples – 2 level hierarchy Tables
Problem
• T1 scans R, and updates a few tuples: Tuples • If we relax the assumption that the DB is a fixed
– T1 gets an SIX lock on R, then get X lock on
tuples that are updated. collection of objects, even Strict 2PL (on individual
items) will not assure serializability:
• T2 uses an index to read only part of R:
– T2 gets an IS lock on R, and repeatedly • Consider T1 – “Find oldest sailor”
gets an S lock on tuples of R. – T1 locks all records, and finds oldest sailor (say, age =
71).
• T3 reads all of R: IS IX SIX S X
– Next, T2 inserts a new sailor; age = 96 and commits.
– T3 gets an S lock on R. IS √ √ √ √ – T1 (within the same transaction) checks for the oldest
– OR, T3 could behave like T2; can IX √ √ sailor again and finds sailor aged 96!!
use lock escalation to decide which. SIX
√ • The sailor with age 96 is a “phantom tuple” from
– Lock escalation dynamically asks for S √ √
courser-grained locks when too many T1’s point of view --- first it’s not there then it is.
X
low level locks acquired • No serial execution where T1’s result could happen!
Data
Predicate Locking Index
Index Locking r=1
• If there is a dense index on the rating field
• Grant lock on all records that satisfy some using Alternative (2), T3 should lock the
logical predicate, e.g. age > 2*salary. index page containing the data entries with
• Index locking is a special case of predicate rating = 1.
locking for which an index supports efficient – If there are no records with rating = 1, T3 must
implementation of the predicate lock. lock the index page where such a data entry
– What is the predicate in the sailor example? would be, if it existed!
• In general, predicate locking has a lot of • If there is no suitable index, T3 must lock all
locking overhead. pages, and lock the file/table to prevent new
pages from being added, to ensure that no
records with rating = 1 are added or deleted.
5
Optimistic CC (Kung-Robinson)
Transaction Support in SQL-92 Locking is a conservative approach in
which conflicts are prevented.
• SERIALIZABLE – No phantoms, all reads Disadvantages:
repeatable, no “dirty” (uncommited) reads. • Lock management overhead.
• REPEATABLE READS – phantoms may • Deadlock detection/resolution.
happen. • Lock contention for heavily used objects.
• READ COMMITTED – phantoms and • Locking is “pessimistic” because it
unrepeatable reads may happen
assumes that conflicts will happen.
• READ UNCOMMITTED – all of them may
happen. • If conflicts are rare, we might get better
performance by not locking, and instead
checking for conflicts at commit.
• Xacts have three phases: • Test conditions that are sufficient to ensure
– READ: Xacts read from the database, but that no conflict occurred.
make changes to private copies of objects. • Each Xact is assigned a numeric id.
– VALIDATE: Check for conflicts. – Just use a timestamp.
– WRITE: Make local copies of changes • Xact ids assigned at end of READ phase, just
public. before validation begins.
old
• ReadSet(Ti): Set of objects read by Xact Ti.
modified ROOT • WriteSet(Ti): Set of objects modified by Ti.
objects new
Test 1 Test 2
• For all i and j such that Ti < Tj, check that:
• For all i and j such that Ti < Tj, check that Ti – Ti completes before Tj begins its Write phase
completes before Tj begins. +
– WriteSet(Ti) ReadSet(Tj) is empty.
Ti
Tj Ti
R V W R V W
Tj
R V W R V W
6
Applying Tests 1 & 2: Serial Validation
Test 3 • To validate Xact T:
• For all i and j such that Ti < Tj, check that: valid = true;
– Ti completes Read phase before Tj does + // S = set of Xacts that committed after Begin(T)
// (above defn implements Test 1)
– WriteSet(Ti) ReadSet(Tj) is empty +
//The following is done in critical section
– WriteSet(Ti) WriteSet(Tj) is empty.
< foreach Ts in S do {
Ti if ReadSet(T) intersects WriteSet(Ts)
R V W start then valid = false;
of
Tj critical
}
R V W section if valid then { install updates; // Write phase
Commit T } >
Does Tj read dirty data? Does Ti overwrite Tj’s writes? else Restart T
end of critical section
7
Summary (Contd.) Summary (Contd.)
• Multiple granularity locking reduces the overhead
• Optimistic CC aims to minimize CC overheads in
involved in setting locks for nested collections of
an ``optimistic’’ environment where reads are
objects (e.g., a file of pages);
common and writes are rare.
– should not be confused with tree index locking!
• Optimistic CC has its own overheads however;
• Tree-structured indexes: most real systems use locking.
– Straightforward use of 2PL very inefficient.
– Idea is to use 2PL on data to ensure serializability and use
• There are many other approaches to CC that we
other protocols on tree to ensure structural integrity. don’t cover here. These include:
– Bayer-Schkolnick illustrates potential for improvement. – timestamp-based approaches
– multiple-version approaches
– semantic approaches