Chapter 19
Transaction Processing Concepts
1.
2.
3. 4. 5. 6. 7.
Introduction to Transaction Processing Transaction and System Concepts Desirable Properties of Transactions Schedules and Recoverability Serializability of Schedules Transaction Support in SQL Summary
19-2
Transaction Processing Concepts
multiprogramming O.S. ( Single CPU)
multiple CPUs
Interleaved concurrency versus Simultaneous concurrency Single-user DBMS Multi-user DBMS
17-1 19-3
Transaction : execution of a program that accesses or changes the contents of the database read_item (X): read a database item into a variable write_item(X): write the value of a variable into the database item
T1 cancels N reservations from one flight and reserves the same number of seats on another flight
T2 reserves M seats on the first flight
Read_set(T1)={X,Y}, write_set (T?)={X,Y} problems: lost update problem temporary update ( dirty read) problem incorrect summary problem
17-2 19-4
Read-item(X)
1.
2.
3.
Find the address of the disk block that contains item X. Copy that disk block into a buffer in main memory. Copy item X from buffer to program variable X.
17-2a
19-5
Write_item(X)
1.
2.
3.
4.
Find the address of the disk block that contains item X. Copy the disk block into a buffer in main memory. Copy item X from program variable X into its correct location in buffer. Stored the updated block from the buffer back to disk
17-2a 19-6
Figure 19.3(a) Lost update problem
5 update
lost
80 cancels 5 seats 75 reserves 4 seats 79
17-3
19-7
Figure 19.3(b) Temporary update problem
dirty data
Computer failure (system crash), transaction or system error, local errors or execution conditions, concurrency control enforcement, dish failure, physical problems
17-3 19-8
Figure 19.3(c) Incorrect Summary Problem (total number of reservation on all fights)
Unrepeatable read
T1 T2
read_item(X) read_item(X) X :=X+5 write_item(X) read_item(X)
17-4 19-9
Transaction: completed in its entirety or not done at all
Concurrency control techniques Recovery protocol
system log
(ROLLBACK)
(ROLLBACK)
System log. (journal) Rept on disk 1. [ start_transaction, T] 2. [ write_item, T, X, old_value, new_value] 3. [ read_item, T, X] 4. [ commit, T] 5. [ about, T] 17-5
19-10
17-5a
19-11
Commit point
All operations that access database have been executed successfully All operations have been recorded in log. Force-writing the log file before committing a file
[start_transaction: on, T]
[commit, T]
The transactions that have not written [commit, T] may have to be rolled back
17-5b
19-12
Check point
The system writes out to the database the results of all WRITE operations of committed transactions.
T1 redone() T3 T4 T2
redone()
redone() ignore System crash
19-13
Checkpoint t1
17-5b
Intervals to take a checkpoint
every m minutes t committed transactions
17-5c
19-14
actions
1.
2.
3.
4.
Suspend execution of transactions. Force-write all update operations of committed transactions from MM to disk. Write [checkpoint] to log, and force-write log to disk. Resume executing transactions.
17-5c
19-15
Desirable Properties of Transactions ACID properties
1.
2.
3.
4.
Atomicity: (recovery method) completed in its entirety or not done at all. Consistency Preservation: (programmer, DBMS) from consistent state to another Isolation: (concurrency control) its updates invisible to other transactions until commit. Durability or permanency: (recovery method) when changes are committed, these changes must never be lost.
17-6 19-16
Isolation (degree isolation of a transaction)
1.
2. 3.
4.
degree 0 isolation: it does not overwrite the dirty reads of higher degree transaction degree 1 isolation: no lost updates degree 2 isolation: no lost updates & no dirty reads degree 3 isolation: no lost updates no dirty reads no repeatable reads
17-6 19-17
Schedules and Recoverabilities
Schedule (history): the order of execution of operations from the various transactions
Sa: r1(X); r2(X); w1(X); r1(X); w2(X); c2; w1(r); c1;
17-7
r : read_item w: write_item c : commit a : abort
19-18
Schedules and Recoverabilities (Cont.)
Sb: r1(X); w1(X); r2(X); w2(X); c2; r1(r); a1;
17-7
19-19
conflict operations: r1(X) and w2 (X) r2(X) and w1 (X) w1(X) and w2 (X)
1. 2. 3.
nonconflict operations: r1(X) and w2 (X) w2(X) and w2 (Y) Y1(X) and w1 (X)
different transactions Access the same item At least one of operations: write_item(X)
17-8 19-20
Schedule S.
1.
transactions T1, T2,, Tn complete schedule
Operations in S: operations in T1,T2,,Tn include a commit or abort as the last operation for each transaction in the schedule
2.
Any pair of operations from the same transaction Ti , their order is kept in S Any two conflicting operations, one of the two most occur before the order in the schedule
19-8-1
3.
19-21
Schedule S. (Cont.)
transactions T1, T2,, Tn complete schedule
T1: r1(X), w1(X), r1(Y), w1(Y)
T2: r2(X), w2(X) Sa: r1(X), r2(X), w1(X), r1(Y), w2(X), c2 ,w1(Y),c1 Sb: r1(X), w1(X), r2(X), w2(X), r1(Y), a1
19-8-1 19-22
Committed projection c(S) of schedule S
Include only the operation is S that belong to committed transactions
19-8-2
19-23
Characterizing Schedules Based on Recoverability which recovery is simple
which recovery is possible
Recoverable Schedule: once a transaction T is committed, it should never be necessary to roll back T. No transaction T in S commits until all transactions T that have written an item that T reads have committed.
T read commit
Recovery algorithm : complex
Sa: r1(X); r2(X); w1(X); r1(Y); w2(X);c2; w1(Y);c1
: recoverable (lost update)
C2 must postpone until T1 commits
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2 ; a1
: not recoverable
If T1 aborts after c2, then the value of X but T2 read is no longer valid T2 should be rolled back !!
Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y);c1;c2
: recoverable
17-9 19-25
Cascading rollback (cascading abort)
Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2
T1 is abortedT2 is rolled back
time-consuming
17-10
19-26
Avoid cascading rollback schedule
read , Se: r1(X); w1(X); write r2(X) is delayed r1(Y); w1(Y); c1; r2(X) w2(X); X=9 w1(X, 5); w2(X, 8); a1;
Every transaction only reads items that were written by committed transactions.
17-10
19-27
Strict Schedule
(recoverable & avoid cascading rollback) Transactions can neither read nor write an read write item X until the last transactions that wrote X has committed (or aborted)
Simplify recovery process
Sf: X=9 w1(X, 5); w2(X, 8); a1; not strict schedule avoid cascading rollback schedule
Restore BFIM of
17-10
19-28
(1) Recoverability (2) Avoidance of cascading rollback (3) Strictness
(2) (1)
(3) (2), (1) (1) (2) (?) (2) (3) (?) (1) (3) (?)
19-10-1 19-29
Figure 19.5 (a) (b)
serial schedule T1 followed by T2 T2 followed by T1
Figure 19.5 (c) Two schedules with interleaving of operation
read old value lost update
nonserial schedule
Every serial schedule is correct A schedule is serializable if it is equivalent to some serial schedule X=90, Y=90, N=3, M=2 T1: X=89 Y=93 C: X=92, Y=93 nonserializable T2: D: X=89, Y=93 serializable
Two schedules are said to be conflict equivalent if the order of any two conflicting operation is the same in both schedules. Sa: r1(X), W2(X) Sb: w2(X), r1(X)
17-12
w1(X), w2(X) w2(X), w1(X)
19-32
A schedule S is conflict serializable if its conflict equivalent to some serial schedule S
A D
r1(X), w1(X), r1(Y), w1(Y), r2(X), w2(X) r1(X), w1(X), r2(X), w2(X), r1(Y), w1(Y)
(A)
(C)
A r1(X), w1(X), r1(Y), w1(Y), r2(X), w2(X) C r1(X), r2(X), w1(X), r1(Y), w2(X), w1(Y)
B r2(X), w2(X), r1(X), w1(X), r1(Y), w1(Y)
C r1(X), r2(X), w1(X), r1(Y), w2(X), w1(Y) C is not equivalent to A and B
Test for Conflict Seralizability of a Schedule Figure 19.7 Precedence Graph (Serialization Graph)
r1(X), w1(X), r1(Y), w1(Y), r2(X), w2(X) r2(X), w2(X), r1(X), w1(X), r1(Y), w1(Y)
T1 must come before T2 in a serial Schedule r1(X), r2(X), w1(X), r1(Y), w2(X), w1(Y)
r1(X), w1(X), r2(X), w2(Y), r1(Y), w1(Y)
(Cont.) Test for Conflict Seralizability of a Schedule
1.
2.
3.
4.
5.
For each Ti in S, create a Ti node in graph For each case in S where Tj executes a r(X) after a w(X) command executed by Ti create Ti Tj For each case in S where Tj executes a w(X) after Ti executes r(X), create Ti Tj For each case in S where Tj execute a w(X) after Ti execute w(X) create Ti Tj S is serializable if graph has no cycles
17-14 19-36
READ and WRITE of three transactions
Schedule E of transactions T1, T2 and T3
Figure 19.8(a)(b)
17-15 19-37
Figure 19.8(c) Schedule F of transactions T1, T2 and T3
17-15
19-38
r2(Z), r2(Y), w2(Y), r3(Y), r3(Z), r1(X), w1(X), w3(Y), w3(Z), r2(X), r1(Y), w1(Y), w2(X) Figure 19.8(d)
17-16
19-39
r3(Y), r3(Z), r1(x), w1(X), w3(Y), w3(Z), r2(Z) r1(Y), w1(Y), r2(Y), w2(Y), r2(X), w2(X)
Figure 19.8(e)
17-16
19-40
17-16
19-41
How to evaluate if a schedule is correct?
A schedule is serializable
How to test for the serializability of a schedule?
Use protocols or set of rules two phase locking, time stamping ordering
How to determine when a schedule begins and when it ends?
Use definition of committed projection c(S): include only the operations in S that belong to committed transaction A schedule S to be seriable if its committed projection is equivalent to some serial schedule
17-17 19-42
Transaction Support in SQL
SQL-transaction: a logical unit of work and atomic Single SQL statement is atomic 1) No explicit BEG2N_TRANSACTION statement 2) Explicit and statement COMMIT or ROLLBACK 3) Characteristics (SET TRANSACTION) access mode diagnostic area size isolation level 19-18 19-43
Characteristics (SET TRANSACTION)
Access mode
READ WRITE (default) update, insert, delete, create READ ONLY retrieval
(let transaction execute in parallel with others)
19-19 19-44
19-19-1
Characteristics (SET TRANSACTION)
Diagnostic area size DIAGNOSTIC SIZE n
The number of conditions that can be held simultaneously in diagnostic area Feed back information
19-19
19-45
Characteristics (SET TRANSACTION)
Isolation level ISOLATION LEVEL <isolation> READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE (default)
19-19 19-46
Choose a Seat
EXEC SQL BEGIN DELLARE SECTION; int flight; char date[10]; char Seat[3]; int occ; EXEC SQL END DELLARE SECTION; void choose Seat() { : : EXEC SQL SET TRANSACTION READ ONLY; EXEC SQL SELECT occupied INTO : occ FROM Flights WHERE fltNam=: flight AND fltDate=: date AND fltSeat=:Seat; if(!occ){ EXEC SQL SET TRANSACTION READ WRITE; EXEC SQL UPDATE Flights SET occupied=B1 WHERE fltNum=:flight AND fltDate=: date AND fltSeat=: Seat; }}
19-19-1 19-47
SERIALIZABLE dirty read, unrepeatable read, phantoms are not allowed.
Dirty Read w2(X), r1(X), , a2 T1 read a value that does not exist and is incorrect in some cases, dirty reads are allowed (19-21)
Nonrepeatable read , r1(X), w2(X), r1(X), T1 Sees a different value at two different times in some cases, non repeatable reads are allowed. (19-22)
19-20 19-48
Phantoms:
, r1(S), w2(t), r1(S),
a set of tuples
phantom
in some cases, phantoms are allowed.
19-20
19-49
SET ISOLATION LEVEL READ UNCOMMITTED
When dirty reads are allowed, the default for access mode is READ ONLY.
Speed up the average processing time for booking request
Example: Seat-choosing 1. We find an available seat and reserve it by setting occupied to 1 for that seat. If there is none, abort.
19-21 19-50
(Cont.) SET ISOLATION LEVEL READ UNCOMMITTED
2.
We ask the customer for approval of the seat. If so, we commit. If not, we release the seat by setting occupied to 0 and repeat step 1 to get another seat.
TA, TB: two transactions A, B choose another seat no seats exist? S1A, S1B, S2A,
Seat S is marked unavailable
Customer rejects S
S available again
19-21 19-51
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
Forbid the reading of dirty (uncommitted) data Allow one transaction to issue the same query several times and get different answers, as long as the answers reflect data that has been written by transactions that already committed.
S1A Seat S is marked unavailable S1B B uncommitted transactions reserve seats S1B b sees a different set of available sets
19-22 19-52
SET TRANSACTION ISOLATION LEVEL REPEATABLE READS (misnomer)
1)
2)
If a tuple is retrieved the first time, then we can be sure that tuple will be retrieved again if the query is repeated. A second or subsequent execution of the same query will retrieve phantom tuples.
S1A Seat S is marked unavailable S1B S2A S1A S and other new seats are available S1B S is still unavailable
19-23
(tuples that are inserted when our transaction is executing) Switch the flight to a larger plane
19-53
Dirty Read READ UNCOMMITTED
READ COMMITTED REPEATABLE READS SERIZABLE
Nonrepeatable phantom Read
yes yes
yes
no
yes
yes
no
no
no
no
yes
no
EXEC SQL WHENEVER SQLERROR GoTo UNDO; EXEC SQL SET TRANSACTION READ WRITE DIAGNOSTICS SIZE 5 ISOLATION LEVEL SERIALIZABLE; EXEC SQL INSERT INT EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY) VALUES (Robert, smith, 991004321, 2, 35000)
EXEC SQL UPDATE EMPLOYEE SET SALARY=SALARY * 1.1 WHERE DON=2;
EXEC SQL COMMITT;
Before this, changes are tentative (may or may not be visible to other GoTo THE END; transaction) UNDO: EXEC SQL ROLLBACK; any changes are undone THE END: ; updated salaries newly inserted row
19-25 19-55
Ch18 Concurrency Control Techniques
Protocols locking timestaming multiversion optimistic Granularity Phantom
18-1 19-56
Concurrency control mechanism avoid the problems similar to lost update problem
A concurrency control mechanism has three places that it could intervene to prevent this inconsistency.
Time t1 t2 t3 t4
Transaction A Read(R) r(R) Write(R) w(R)
Transaction B Read(R) r(R) Write(R) w(R)
a) At time t2, it could deny B access R, because A has already read it (and is likely to change it)
11-3 19-57
b) At time t3, it could refuse to let A write a new value for R, because B is looking at the old value.
c) At time t4, it could refuse to let B write a new value for R, because its update is based on the incorrect value of R.
(a) and (b) locking (b) and (c) timestamping tradeoff : system overhead vs. parallelism
11-3 19-58
Exclusive Locks
Locking a technique for regulating concurrent access to shared objects.
Transaction request Lock Manager
Lock
Record
11-4 19-59
Exclusive Locks (Cont.)
Lock type
Exclusive Locks Shared Locks Update Locks Binary Locks Shared Locks Exclusive Locks
Locking Techniques
Binary Locks
Locked Unlocked
18-2 19-60
(a) Figure 20.1 Lock and unlock operations for binary locks
(indivisible unit) (indivisible unit)
1. A transaction must issue lock_item(X) before read_item(X) or write_item(X) 2. A transaction must issue unlock_item(X) after read_item(X) and write_item(X) 3. A transaction will not issue lock_item(X) if it already holds lock on X 4. A transaction will not issue unlock_item(X) unless it already holds lock on X <data item name, locks> + queues for waiting transactions
18-2 19-61
(b) Figure 20.2 Shared and Exclusive Locks read-locked (share-locked) write-locked (exclusive-locked) unlocked
(indivisible unit)
18-3
19-62
Figure 20.2 Shared and Exclusive Locks (Cont.)
(indivisible unit)
18-3
19-63
Figure 20.2
Shared and Exclusive Locks (Cont.)
(indivisible unit)
<data_item name, Lock, no_of_reads> Read_locked, write_locked, unlocked
18-3 19-64
Multiple-mode locking scheme
1.
A transaction must issue read_lock(X) or write_lock(X) before read_item(X)
2.
A transaction must issue write_lock(X) before write_item(X)
A transaction must issue unlock(X) after read_item(X) and write_item(X)
18-4 19-65
3.
Multiple-mode locking scheme (Cont.)
4.
5.
6.
A transaction will not issue read_lock(X) if it already holds a read (shared) lock or write (exclusive) lock on X upgrade (relax) A transaction will not issue write_lock(X) if it already holds a read (shared) lock or write (exclusive) lock on X. downgrade (relax) A transaction will not issue an unlock(X) unless it already holds a read lock or write lock on it. 18-4 19-66
Two-phase locking protocol all locking operations precede the first unlock operation in the transaction. Expanding (growing) phase new locks on items can be acquired but none can be released Shrinking phase existing locks can be released but no new locks can be acquired Upgrading of locks unchanged Downgrading of locks done in the shrinking phase
18-5 19-67
T1 & T2 dont follow 2 phase protocol
Nonserializable Schedule
old value
18-6
Figure 20.3
19-68
T1 & T2 follow 2 phase locking protocol
Expanding phase Shrinking phrase
18-7
19-69
Basic 2-phase locking protocol Advantage: guaranteeing serializability without having to check the schedules themselves Disadvantages : limiting the amount of concurrency deadlock livelock Predeclare read set write set Conservative 2-phase locking: (dead lock free) lock before start lock all the item it accesses before transaction begin Strict 2-phase locking: (not dead lock free) unlock after terminate transaction does not release any locks until commit or abort
18-7 19-70
Conservative 2PL (static 2PL)
Lock all the items it accesses before transaction begins Transaction start (lock before start)
Shrinking phase
predeclare
read set write set (dead lock free protocol)
18-7.1
19-71
Strict 2PL
Transaction does not release any write locks until commit or abort (exclusive) (unlock after terminate) Expanding phase (not dead lock free) Guarantee strict schedule
Transaction terminate
transactions can neither read nor write an item X
until the last transaction that wrote X has
committed (or aborted)
18-7.1 19-72
Rigorous 2PL
A transaction T does not release any of its lock (exclusive or shared) until it commits or aborts concurrency control subsystem (strict 2PL protocol)
18-7.2
19-73
Transaction T system 1) read_item(X) read_lock(X)
resource X (a) write_locked by T1 T: waiting queue (b) available read_lock(X)
2) write_item(X) write_lock(X)
(a) write_locked or read_locked by T T:waiting queue (b) read_locked by T only write_lock(X) (c) available
write_lock(X)
(Cont.) Transaction T system 3) Unlock(X) grant write_lock
resource X
(a) waiting queue
Every schedule that is permitted is serializable. Not all possible serializable schedule are permitted. dead lock problems starvation
18-7.3 19-75
18-8
19-76
Dealing with Deadlock and Livelock
Deadlock prevention protocol
Conservative
Every transaction locks all the items it needs in advance. limit concurrency
two-phase locking
Wait-die
and wound-wait
Ti tries to lock an item hold by Tj
T1
if TS(Ti) < TS(Tj) then Ti is allowed to wait. t1 < t2 << tn < t1 Otherwise abort Ti ( Ti die) & eate restart it with the same timestamp older transaction waits on younger transaction
T2
Wait-die:
Tn
T1
18-8a
19-77
(Cont.) Dealing with Deadlock and Livelock
wound-wait: if TS(Ti) < TS(Tj) then abort Tj is ( Ti wounds Tj) & restart it (ate with the same timespamp otherwise Ti is allowed to wait. younger transaction waits on old transaction
T1 T2
Tn
T1
t1 > t2 >> tn > t1
18-8a
19-78
No Waiting
If a transaction is unable to obtain a lock, it is immediately aborted and then restarted after a certain time delay.
18-9
19-79
Cautious Waiting
Ti tries to lock an item X that is locked by Tj if Tj is not blocked then Ti is blocked and allowed to wait otherwise abort Ti blocking time form a total ordering
T1 T2
Tn
T1
b(T1) <b(T2)<<b(Tn)<b(T1) ? b(T): time at which T was blocked
18-9 19-80
Deadlock Detection Mechanism
Periodically check if the system is deadlock setup wait-for graph check for deadlock (cycle) select the victim Timeout if a transaction waits for a period longer than a system-defined timeout period, then the transaction is aborted
18-9.1 19-81
Line Lock
First come first serve
18-9.1
19-82
Timestamp Techniques = do not use locks
Each transaction is assigned a unique identifier (the timestamp) transaction start time Timestamp is thought of as transactions start-time order transactions based on timestamps Where does a conflict occur?
(1) Time t1 t2 (2) Time t1 t2 (3) Time t1 t2 UPD R W(R) Transaction A t A UPD R FIND R r(R) older Transaction A t A FIND R r(R) Transaction A t A
< tB
younger Transaction B UPD R W(R)
< tB Transaction B
< tB Transaction B
UPD R W(R)
19-83
11-47
Time t1 t2 (b) t3 (c) t4
Transaction A FIND R r(R)
Transaction B
FIND R r(R)
UPD R w(R)
UPD R w(R)
(1) Assumption:A is younger than B. timestamp (A) > timestamp (B) B will restart at t4 case(c) (2) Assumption:A is older than B timestamp(A) < timestamp(B) A will restart at t3 case(b)
11-48
19-84
Concurrency Control Based on Timestamp Ordering
Timestamps created by DBMS to identify a transaction Timestamp ordering The equivalent serial schedule has the transaction in the order of their
timestamping value
18-10 19-85
Concurrency Control Based on Timestamp Ordering (Cont.)
Each database item X with two timestamp (TS) values:
1.
2.
Read_TS(X): read timestamp largest (youngest) timestamp among all the timestamps of transactions that have successfully read item X. Write_TS(X): write timestamp largest (youngest) timestamp of all the transactions that have successfully written item X
18-10 19-86
Basic Timestamp Ordering
1. Transaction T issues a write_item(X)
a.
b.
If read_TS(X)>TS(T) or write_TS(X)>TS(T) then abort and roll back T and reject the operation. abort: resubmit to the system as a new transaction with a new timestamp roll back: cascading roll back Otherwise, execute write_item(X) and set write_TS(X) to TS(T)
18-11 19-87
(2)
(3)
Basic Timestamp Ordering (Cont.)
2. Transaction T issues a read_item(X) a. If write_TS(X) > TS(T), then abort and roll back T and reject the operation b. If write_TS(X) <= TS(T), then execute read_item(X) and set read_TS(X) =max( TS(T), read_TS(X) )
Detect two conflicting operations in incorrect order. Deadlock does not occur. Reject the latter Cyclic restart may occur.
18-11 19-88
Conflict serializable
Strict Timestamp Ordering
Ensure both conflict serializability and recoverable schedule A transaction T that issues a read_item(X) or write_item(X) such that TS(T) > write_TS(X) has its read or write operation delayed until the transaction T that wrote the value of X has committed or aborted
18-11a 19-89
Locking Granularity What is the unit of locking? concurrency overhead an entire database, the set of records of a given type, individual record, specific field within a record. Small # of records: record many records: file tradeoff: (depend on types of transactions involved) the finer the greater the concurrency, the coarse the lower the overhead.
11-38 19-90
Implementation Principle No. 1: The system can safely lock more than the minimum requested.
Implementation Principle No. 2: The system can safely retain locks longer than requested.
11-38
19-91
Using Locks for Concurrency Control in Indexes (disk pages)
Search (read) a path is traversed from the root to a leaf
Once a read lock on the child is obtained, the
lock on the parent can be released.
Insertion (write) insertion to a leaf node, the node must be locked in exclusive mode.
Not full Full: insertion upward
18-12 19-92
Conservative Approach for Insertions
1.
Lock the root node in exclusive mode and then access the appropriate child node of the root. If the child node is not full, then the lock on the root node can be released
2.
18-13
19-93
Optimistic Approach for Insertions
1.
Request and hold shared locks on the nodes leading to the leaf node. Exclusive lock on the leaf
2.
3.
Leaf is split. Locks on the higher level nodes are upgraded to exclusive mode.
18-13 19-94
B-link tree:
a variant of the B+-tree Sibling nodes on the same level are linked together at every level (1) Shared lock is used when requesting a page (2) the lock is released before releasing the child node.
(3) For insertion, the shared lock on a node would be
upgraded to exclusive mode. Search operations are executed concurrency with the update split
18-14 19-95
P node:
m, A0, (K1, A1),,(Km, Am) Ki< Ki+1, 1 i m
split
1, A0 ,( K1 , A1 ),...( K
P node:
m 2
k
,A m
q node: m m
, A m ,( K m 1 , A m 1 )...,( K m , Am ) 2 2 2 2
Insert (
(1)When the insert is done, the search process resumes. (2)The key it is locking for is not present the split has moved that key into a new leaf node right sibling of the original node i.e.q
18-15 19-96
,q) to parent of P.
Phantom Problem Example: F, G, H: fields in the database A, B: transactions A. if F exists then G:=1; else G:=0: B. if F does not exist Initially: then F does not exist do; A-then-B: create F; F exists, G=1 G:=1; B-then-A: end; F exists, G=1
11-31 19-97
Interleaved execution of A and B: F exists, G=0 not serializable two phase locking is not valid?
11-32 19-98
Nonexistence of data phantom Update the nonexistence INSERT operation
Transaction A
FIND F: r(F) Not found
Time
t1
Transaction B
XFIND G
t2
t7 t8 t9
UPD G: Replace G by 0 COMMIT
Implementation: index locking 11-33
SFIND F Wait Wait Wait Wait Wait Wait Wait Wait Wait Wait Wait resume
19-99
Phantom problem:
A new record that is being inserted by some transaction T satisfies a condition that a set of records accessed by another transaction T must satisfy.
18-16
19-100
Phantom problem: (Cont.)
T : insert a new EMPLOYEE record whose DNo=5 T: access all EMPLOYEE records whose DNo=5 T T T T
Example:
Index locking
T: request a read lock on index entry for DNo=5 T : request a write lock on the same entry before placing locks on actual records
18-16 19-101