Chapter 15 : Concurrency Control

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 15: Concurrency Control
● Isolation
● The fundamental properties of a transaction
● When several transactions execute concurrently in the database
● The isolation property may no longer be preserved
4 So, the system must control the interaction among the concurrent
transactions
● The control is achieved through mechanism called concurrency
control schemes

Database System Concepts - 6th Edition 15.2 ©Silberschatz, Korth and Sudarshan
 Concurrency Control vs. Serializability Tests

● Testing a schedule for serializability after it has executed

is a little too late!
● Goal – To develop concurrency control protocols that
will assure serializability
● They will generally not examine the precedence graph
as it is being created;
● Instead a protocol will impose a discipline that avoids
nonserializable schedules
● Require study of concurrency protocols in Chapter 15.
● Tests for serializability help understand why a
concurrency control protocol is correct

Database System Concepts - 6th Edition 15.3 ©Silberschatz, Korth and Sudarshan
 Chapter 15: Concurrency Control

● Lock-Based Protocols
● Timestamp-Based Protocols
● Validation-Based Protocols
● Multiple Granularity
● Multiversion Schemes
● Insert and Delete Operations
● Concurrency in Index Structures

● Most frequently used schemes

● Two-Phase Locking
● Snapshot Isolation
Database System Concepts - 6th Edition 15.4 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols

● A lock is a mechanism to control concurrent access to a data

item
● To allow MULTIPLE transactions to READ a data item
● But, limits WRITE access to just ONE transaction at a
time
● Every transaction require a lock on data item Q in an
appropriate mode depending upon the type of operations it
will perform on the data item Q
● Transaction makes Lock requests to concurrency-control
manager
● Transaction can proceed only after request is granted

Database System Concepts - 6th Edition 15.5 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols

● Data items can be locked by transaction in two modes

1. Exclusive (X) mode
Data item Q can be both read as well as written
X-lock is requested using lock-X(Q) instruction
2. Shared (S) mode
Data item can only be read
S-lock is requested using lock-S(Q) instruction

● To unlock a data item Q using Unlock(Q) instruction

Database System Concepts - 6th Edition 15.6 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)

● Lock-compatibility matrix

● A transaction may be granted a lock on an item if the

requested lock is COMPATIBLE with locks already held
on the item by other transactions

Database System Concepts - 6th Edition 15.7 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)

● Lock-compatibility matrix
● ANY NUMBER of transactions can hold SHARED locks
on an item,
● But if any transaction HOLDS AD EXCLUSIVE on the
item NO OTHER TRANSACTION may hold any lock on
the item
● If a lock cannot be granted,
● The requesting transaction is made to wait till all
incompatible locks held by other transactions have been
released,
● Then only the lock is granted

Database System Concepts - 6th Edition 15.8 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols
Transaction 1 Transaction 2
• Banking Example read (B) read (A)
• T1 transfers $50 from Acct B to Acct A B=B-50 read (B)
• T2 displays the total money in Acct A and write (B) Display (A+B)
B read (A)
A=A+50
• A=$100
write (A)
• B=$200
• If schedule,
• T1 T2, then A+B=300
• T2 T1, then A+B=300

• Now, add lock information

Database System Concepts - 6th Edition 15.9 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols
Transaction 1 Transaction 2
• Banking Example
lock-X(B) lock-S(A)
• T1 transfers $50 from Acct B to Acct A read (A)
read (B)
• T2 displays the total money in Acct A and B=B-50 unlock (A)
B write (B) lock-S(B)
• A=$100 unlock (B) read (B)
lock-X(A) unlock (B)
• B=$200
read (A) Display (A+B)
• If schedule, A=A+50
• T1 T2, then A+B=300 write (A)
• T2 T1, then A+B=300 unlock (A)

Database System Concepts - 6th Edition 15.10 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols
Shows points at which the concurrency-contro
• The transaction making a manager grants the locks
lock request cannot execute
its next action until the
concurrency control manager
grants the lock
• Hence, the lock must be
granted in the interval of time
between the lock-request
operation and the following
action of the transaction

Schedule 1

Database System Concepts - 6th Edition 15.11 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols
• Transactions are executed
concurrently
• T2 displays $250
• As T1 unlocked data item B too
early
• Inconsistent state

Schedule 1

Database System Concepts - 6th Edition 15.12 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols
Transaction 3 Transaction 4
• Banking Example (UNLOCKING
DELAYED) lock-X(B)
read (B)
• T3 transfers $50 from Acct B to Acct A
B=B-50
• T4 displays the total money in Acct A and write (B)
B lock-X(A)
• A=$100 read (A)
• B=$200 A=A+50
write (A)
• No possibility of incorrect display of total unlock (B)
$250 unlock (A)
• Consistent state lock-S(A)
read (A)
lock-S(B)
read (B)
Display (A+B)
unlock (A)
unlock (B)

Database System Concepts - 6th Edition 15.13 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols
1. Consider the partial schedule

● Neither T3 nor T4 can make progress — executing

● lock-S(B) causes T4 to wait for T3 to release its lock on B, while
● lock-X(A) causes T3 to wait for T4 to release its lock on A
● Such a situation is called a deadlock

Database System Concepts - 6th Edition 15.14 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols
● Solution to deadlock

● To handle a deadlock one of the two transactions (T3 or T4 ) must

ROLL BACK and release locks of that transaction
● The potential for deadlock exists in most locking protocols

Database System Concepts - 6th Edition 15.15 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols (Cont.)

2. Starvation is also possible, if concurrency control manager is badly designed

● For example:
4 A sequence of transactions that each requests a S-lock on the data item
and each transactions releases the lock a short while after it is granted,
but Tx never gets the X-lock on the data item
– The Transaction Tx may never make progress, and said to be
starved
4 A transaction may be waiting for an X-lock on an item, while a
sequence of other transactions request and are granted an S-lock
on the same item
4 The same transaction Tx is repeatedly rolled back due to deadlocks
● Concurrency control manager can be designed to prevent starvation

Database System Concepts - 6th Edition 15.16 ©Silberschatz, Korth and Sudarshan
 Prevent Starvation
● Avoid starvation of transactions by granting locks as shown
● When a transaction Ti requests a lock on a data item Q in a
particular mode M, the concurrency-control manager grants the
lock provided that:
1. There is no other transaction holding a lock on Q in a mode
that conflicts with M
2. There is no other transaction that is waiting for a lock on Q
and that made its lock request before Ti
● Thus, a lock request will never get blocked by a lock request that
is made later

Database System Concepts - 6th Edition 15.17 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)
● Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);
lock-S(B);
read (B);
unlock(B);
display(A+B)
● Locking is not sufficient to guarantee serializability
● if A and B get updated in-between the read of A and B, the displayed
sum would be wrong
● A locking protocol is a set of rules followed by all transactions while
requesting and releasing locks

Database System Concepts - 6th Edition 15.18 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)

● Locking protocols
● Restrict the set of possible schedules
● The set of all such schedules is a proper subset of all
possible serializable schedules
● Allow only conflict serializable schedule

Database System Concepts - 6th Edition 15.19 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking Protocol

● A protocol which ensures conflict-serializable schedules

● Requires two phases
● Phase 1: Growing Phase
4 Transaction may obtain locks
4 Transaction may not release locks
● Phase 2: Shrinking Phase
4 Transaction may release locks
4 Transaction may not obtain locks

Database System Concepts - 6th Edition 15.20 ©Silberschatz, Korth and Sudarshan
 Check Transaction for Two-Phase Locking Property

•Transactions T1 and T2 are not two phase, here mix of lock and unlock
•While, Transactions T3 and T4 are two phase, as all locks first and then all
unlock
•Clear boundary where the transaction has obtained its final lock (the end
of its growing phase) is known as lock point (a point of final lock)

Database System Concepts - 6th Edition 15.21 ©Silberschatz, Korth and Sudarshan
 Check Transaction for Two-Phase Locking Property

• The unlock instructions do not need to appear at the end of the transaction
• For example, in the case of transaction T3, we could move the unlock(B)
instruction to just after the lock-X(A) instruction, and still retain the
two-phase locking property

Database System Concepts - 6th Edition 15.22 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking Protocol

● The protocol assures serializability

● Can be proved that the transactions can be serialized in
the order of their lock points (i.e. the point where a
transaction acquired its final lock the end of its
growing phase)
4 Now, transactions can be ordered according to their
lock points—this ordering is, in fact, a
serializability ordering for the transactions

Database System Concepts - 6th Edition 15.23 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking Protocol

● The protocol assures serializability, BUT NOT ENSURE

FREEDOM FROM DEADLOCK

Database System Concepts - 6th Edition 15.24 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking Protocol
● To being serializable schedule, schedules should be cascadeless
● But, cascading rollback may occur

● Here in this schedule, the failure of T5 after the read(A) step of T7 leads to
cascading rollback of T6 and T7

Database System Concepts - 6th Edition 15.25 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol (Cont.)

● Pitfalls
● Does not ensure freedom from deadlocks
● Cascading roll-back is possible
● Solution to Two-Phase Locking Protocol (Used commercially)
1. Strict two-phase locking is a modified protocol
4 Transaction must hold all its Exclusive locks till it commits/aborts
4 Preventing any other transaction from reading the data
2. Rigorous two-phase locking is even stricter
4 Here all locks are held till commit/abort
4 In this protocol transactions can be serialized in the order in which
they commit

Database System Concepts - 6th Edition 15.26 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
● If, Two-phase locking
● Then T8 must lock a1 in exclusive mode, therefore, any
concurrent execution of both transactions amounts to a
serial execution
● However, T8 needs an exclusive lock on a1 only at the end
of its execution, when it writes a1
● Thus, if T8 could initially lock a1 in shared mode, and
then could later change the lock to exclusive mode, we
could get more concurrency, since T8 and T9 could
access a1 and a2 simultaneously
● Solution
● A refinement of the basic two-phase locking protocol
4 Lock conversions

Database System Concepts - 6th Edition 15.27 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
● A mechanism for upgrading a shared lock to an exclusive lock, and
downgrading an exclusive lock to a shared lock
● Conversion
● From shared to exclusive modes by upgrade, and
● From exclusive to shared by downgrade
● Lock conversion cannot be allowed arbitrarily, Rather
● Upgrading can take place in only the growing phase
● Downgrading can take place in only the shrinking phase

Database System Concepts - 6th Edition 15.28 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
● Two-phase locking with lock conversions:
– First Phase:
● Can acquire a lock-S on item
● Can acquire a lock-X on item
● Can convert a lock-S to a lock-X (upgrade)
– Second Phase:
● Can release a lock-S
● Can release a lock-X
● Can convert a lock-X to a lock-S (downgrade)
● This protocol assures serializability
● But still relies on the programmer to insert the various locking
instructions

Database System Concepts - 6th Edition 15.29 ©Silberschatz, Korth and Sudarshan
 Lock Conversions

Incomplete Schedule with lock conversion

● TransactionsT8 and T9 can run concurrently under the refined two-phase
locking protocol (here shown only some of the locking instructions)
● A transaction attempting to upgrade a lock on an item Q may be
forced to wait
4 Enforced wait occurs if Q is currently locked by another
transaction in shared mode (T8 last line in schedule)

Database System Concepts - 6th Edition 15.30 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
● Like the two-phase locking protocol, two-phase locking with lock
conversion generates
● Only conflict-serializable schedules
4 Transactions can be serialized by their lock points
● If exclusive locks are held until the end of the transaction
● Then, the schedules are cascadeless

Database System Concepts - 6th Edition 15.31 ©Silberschatz, Korth and Sudarshan
 Automatic Acquisition of Locks
● A transaction Ti issues the standard read/write instruction, without explicit
locking calls
● The operation read(D) is processed as:
if Ti has a lock on D
then
read(D)
else begin
if necessary wait until no other transaction has a
lock-X on D
grant Ti a lock-S on D;
read(D)
end

Database System Concepts - 6th Edition 15.32 ©Silberschatz, Korth and Sudarshan
 Automatic Acquisition of Locks (Cont.)
● The operation write(D) is processed as:
if Ti has a lock-X on D
then
write(D)
else begin
if necessary wait until no other trans. has any lock on D,
if Ti has a lock-S on D
then
upgrade lock on D to lock-X
else
grant Ti a lock-X on D
write(D)
end;

● All locks are released after commit or abort

Database System Concepts - 6th Edition 15.33 ©Silberschatz, Korth and Sudarshan
 Implementation of Locking
● Lock manager can be implemented as a separate process to which
transactions send lock and unlock requests
● It replies, to a lock request by sending
4 A lock grant messages
4 A message asking the transaction to roll back (in case of a
deadlock)
● The requesting transaction waits until its request is answered
● It maintains a data-structure called a lock table to record granted
locks and pending requests

Database System Concepts - 6th Edition 15.34 ©Silberschatz, Korth and Sudarshan
 Lock Table
● Implemented as an in-memory hash table
indexed on the name of the data item being
locked
● Data item maintains link list of
transaction record, one for each request,
in the order in which the requests
arrived
● Data Items
● 17, 1912, 14, 144 and 123
● Colored rectangles
● Dark indicate granted locks
● Light indicate waiting requests
● It also records the type of lock granted or
requested (here not shown)

Database System Concepts - 6th Edition 15.35 ©Silberschatz, Korth and Sudarshan
 Lock Table
● Example: Transaction T23 has been
● Granted locks on items 1912 and 17
● Waiting for a lock on item 14
● When lock request arrives
Step 1. if link list is present
4 Adds a record to the end of the link
list queue of requests for the data
item,
4 OR creates a new link list
Step 2. Either Grants,
4 If not currently locked, or If it is
compatible with all earlier locks and
ALL EARLIER REQUESTS HAVE
BEEN GRANTED
4 OR Waits

Database System Concepts - 6th Edition 15.36 ©Silberschatz, Korth and Sudarshan
 Lock Table
● When unlock request arrives
Step 1. Deletes the record for that data item
in the linked list corresponding to that
transaction
Step 2. Also it checks, following requests
are checked to see if they can now be
granted. If it can, grants the request and
process the record following it and so on

● If transaction aborts
● Deletes all waiting or granted requests of
the transaction
● Lock manager may keep a list of locks
held by each transaction, to implement
this efficiently (that helps in Recovery
Ch. 16))

Database System Concepts - 6th Edition 15.37 ©Silberschatz, Korth and Sudarshan
 Lock Table
● Advantages
● Freedom from starvation for lock
requests
4 As request can never be granted
while a request received earlier is
waiting to be granted
● Deadlock can occur
4 But, Deadlock can be resolved
(later section)

Database System Concepts - 6th Edition 15.38 ©Silberschatz, Korth and Sudarshan
 Graph-Based Protocols
● An alternative to two-phase locking
● Based on PRIOR KNOWLEDGE
● About the order in which the database items will be accessed
● Impose a partial ordering → on the set D = {d1, d2 ,..., dh} of all data items
● If di → dj then any transaction accessing both di and dj must access di
before accessing dj
● Implies that the set D may now be viewed as a directed acyclic graph,
called a database graph
4 Considering Graphs as Rooted Trees
● A simple kind of graph protocol
● The tree-protocol
4 Considering only exclusive locks (lock-x)

Database System Concepts - 6th Edition 15.39 ©Silberschatz, Korth and Sudarshan
 Tree Protocol
● Transaction Ti can lock a data item by
following rules:
1. The FIRST lock by Ti may be on ANY
data item
2. Subsequently, a data item Q can be locked
by Ti only if the parent of Q is currently
locked by Ti
3. Data items may be unlocked at any time
4. A data item that has been locked and
unlocked by Ti cannot subsequently be
relocked by Ti

Database System Concepts - 6th Edition 15.40 ©Silberschatz, Korth and Sudarshan
 Tree Protocol
● Four Transactions
● T10 : lock-x(B), lock-x(E), lock-x(D),
unlock(B), unlock(E), lock-x(G),
unlock(D), unlock (G)
● T11 : lock-x(D), lock-x(H), unlock(D),
unlock (H)
● T12 : lock-x(B), lock-x(E), unlock(E),
unlock(B)
● T13 : lock-x(D), lock-x(H), unlock(D),
unlock (H)

Database System Concepts - 6th Edition 15.41 ©Silberschatz, Korth and Sudarshan
 Tree Protocol Serialized Schedule

● Transaction T10 holds locks on two disjoint subtrees

Database System Concepts - 6th Edition 15.42 ©Silberschatz, Korth and Sudarshan
 Graph-Based Protocols (Cont.)
● Tree Protocol
● Ensures conflict serializability
● Advantages over two-phase locking
● Free from deadlock, so no rollbacks are required
● Unlocking may occur earlier
4 Leads to shorter waiting times
4 Increases concurrency

Database System Concepts - 6th Edition 15.43 ©Silberschatz, Korth and Sudarshan
 Graph-Based Protocols (Cont.)
● Tree Protocol Drawbacks
● Transactions may have to lock data items that they do not access
4 Increased locking overhead, and additional waiting time
4 Potential decrease in concurrency
● Protocol does not guarantee recoverable or cascadelessness schedules
4 To achieve this, protocol can be modified by not permitting x-lock until
the end of transaction
– But, that reduces concurrency
4 To achieve recoverability, need to introduce commit dependencies

Database System Concepts - 6th Edition 15.44 ©Silberschatz, Korth and Sudarshan
 Graph-Based Protocols (Cont.)
● Commit dependencies
● For each data item with an uncommitted write, record which transaction
performed the last write to the data item
● When transaction Ti reads uncommitted data, record the commit
dependency of Ti transaction that performed the last write to the data
item
● Transaction Ti is not permitted to commit until the commit of all
transactions on which it has a commit dependency
● If any of these transactions aborts, Ti must also be aborted

Database System Concepts - 6th Edition 15.45 ©Silberschatz, Korth and Sudarshan
 Deadlock Handling
● Consider the following two transactions:
T1: write (X) T2: write(Y)
write(Y) write(X)
● Schedule with deadlock

● System is deadlocked if there is a set of transactions such that every

transaction in the set is waiting for another transaction in the set

Database System Concepts - 6th Edition 15.46 ©Silberschatz, Korth and Sudarshan
 Deadlock Handling Methods
1. Deadlock Prevention
● Ensures that the system will never enter into a deadlock state
2. Deadlock Detection and Recovery
● Allow the system to enter a deadlock state and then try to recover

● Utilize, If the probability that the system would enter a deadlock state,
● Relatively high
4 Deadlock Prevention
● Low
4 Deadlock Detection and Recovery

Database System Concepts - 6th Edition 15.47 ©Silberschatz, Korth and Sudarshan
 Deadlock Prevention
1. Deadlock Prevention Schemes based on
A. The ordering of lock requests or all locks to be acquired together
B. Using transaction rollback instead of waiting for a lock

Database System Concepts - 6th Edition 15.48 ©Silberschatz, Korth and Sudarshan
 Deadlock Prevention
A. Deadlock Prevention Schemes based on ordering and all locks together
● Impose partial ordering of all data items and require that a transaction
can lock data items only in the order specified by the partial order
(graph-based protocol)
4 Disadvantages
– Transactions may have to lock data items that they do not access
and thus increased locking overhead, additional waiting time and
decrease in concurrency
– Protocol does not guarantee recoverable or cascadelessness
schedules

Database System Concepts - 6th Edition 15.49 ©Silberschatz, Korth and Sudarshan
 Deadlock Prevention
A. Deadlock Prevention Schemes based on ordering and all locks together
● Require that each transaction locks all its data items before it begins
execution (predeclaration)
4 Disadvantages
– Before the transaction begins, it is hard to predict, what data
items need to be locked
– Data item utilization may be very low, as many of data items may
be locked but unused for a long time

Database System Concepts - 6th Edition 15.50 ©Silberschatz, Korth and Sudarshan
 Deadlock Prevention
B. Deadlock Prevention Schemes using Rollbacks
● Uses the concept of Preemption
4 When a transaction Tx requests a lock that transaction Ti holds, the
lock granted to Ti may be preempted by rolling back of Ti and
granting of the lock to Tx
4 To decide whether to roll back or wait, assigns transaction timestamp
based on a
1. Counter
Time stamp is the value of the counter when the transaction
enters the system
Incremented after a new timestamp has been assigned
2. System clock
Value of the clock when the transaction enters the system

Database System Concepts - 6th Edition 15.51 ©Silberschatz, Korth and Sudarshan
 Deadlock Prevention
B. Deadlock Prevention Schemes using Rollbacks
4 If the transaction is rollback, it retains the old timestamp when
restarted
4 Schemes
– wait-die and wound-wait

Database System Concepts - 6th Edition 15.52 ©Silberschatz, Korth and Sudarshan
 More Deadlock Prevention Strategies
● Transaction timestamp based schemes for the deadlock prevention
● wait-die scheme — non-preemptive
4 Allows the older transaction to wait but kills the younger one
4 If TS(Ti) < TS(Tj) : Ti is older than Tj − then, Ti is allowed to wait
» Older transaction may wait for younger one to release data item
4 If TS(Ti) > TS(tj) : Ti is younger than Tj − then Ti dies and Ti is restarted
later with a random delay but with the same timestamp
» Younger transactions never wait for older ones; they are rolled back
instead
4 Transaction may die several times before acquiring needed data item

Database System Concepts - 6th Edition 15.53 ©Silberschatz, Korth and Sudarshan
 More Deadlock Prevention Strategies
● Transaction timestamp based schemes for the deadlock prevention
● wait-die scheme — non-preemptive
4 Example
4 Transaction T22, T23, T24 have time-stamps 5, 10 and 15 respectively
– (5 is older timestamp, 15 younger timestamp)
– If T22 requests a data item held by T23 then T22 will wait
– If T24 requests a data item held by T23, then T24 will be rolled back

Database System Concepts - 6th Edition 15.54 ©Silberschatz, Korth and Sudarshan
 More Deadlock Prevention Strategies
● Transaction timestamp based schemes for the deadlock prevention
● wound-wait scheme — preemptive
4 Older transaction wounds (forces to abort or release the item by
rollback ) of younger transaction instead of waiting for it
4 If TS(Ti) < TS(Tj), then
– Ti forces Tj to be rolled back − that is Ti wounds Tj
– Tj is restarted later with a random delay but with the same
timestamp
4 Younger transactions may wait for older ones
4 If TS(Ti) > TS(Tj), then Ti is forced to wait until the data item is
available

Database System Concepts - 6th Edition 15.55 ©Silberschatz, Korth and Sudarshan
 More Deadlock Prevention Strategies
● Transaction timestamp based schemes for the deadlock prevention
● wound-wait scheme — preemptive
4 Example
4 Transactions T22, T23, T24 have time-stamps 5, 10 and 15 respectively
– If T22 requests a data item held by T23, then data item will be
preempted from T23 and T23 will be rolled back
– If T24 requests a data item held by T23, then T24 will wait

Database System Concepts - 6th Edition 15.56 ©Silberschatz, Korth and Sudarshan
 Deadlock prevention (Cont.)
● Time-stamp based Schemes
● Wait-Die „
4 Wait: If Ti is older than Tj, then Ti waits
4 Die: If Ti is younger than Tj, then abort Ti
● Wound-Wait „
4 Wound: If Ti is older than Tj, then abort Tj
4 Wait: If Ti is younger than Tj, then Ti waits
● Rolled back transactions are restarted with its original timestamp
● Older transactions thus have precedence over newer ones, and
starvation is hence avoided

Database System Concepts - 6th Edition 15.57 ©Silberschatz, Korth and Sudarshan
 Deadlock prevention (Cont.)
● Timeout-Based Schemes
● A transaction waits for a lock only for a specified amount of time
After that, the wait times out and the transaction is rolled back
4 Thus deadlocks are not possible
● Simple to implement; but starvation is possible
● Also difficult to determine good value of the timeout interval

Database System Concepts - 6th Edition 15.58 ©Silberschatz, Korth and Sudarshan
 Deadlock Detection & Recovery
● Aborting a transaction is not always a practical approach
● Instead, deadlock avoidance mechanisms can be used to detect any
deadlock situation in advance
● Method "wait-for graph“
4 Suitable for only those systems where transactions are
lightweight having fewer instances of resource
4 In a bulky system, deadlock prevention techniques may work
well

Database System Concepts - 6th Edition 15.59 ©Silberschatz, Korth and Sudarshan
 Deadlock Detection
● wait-for graph
● Consists of a pair G = (V,E),
4 V is a set of vertices (all the transactions in the system)
4 E is a set of edges; each element is an ordered pair Ti →Tj
● If Ti → Tj is in E, Directed edge from Ti to Tj,
4 Implying that Ti is waiting for Tj to release a data item
● When Ti requests a data item currently being held by Tj, then the edge Ti
Tj is inserted in the wait-for graph
4 This edge is removed only when Tj is no longer holding a data item
needed by Ti
● The system is in a deadlock state if and only if the wait-for graph has a
cycle
4 Must invoke a deadlock-detection algorithm periodically to look for
cycles

Database System Concepts - 6th Edition 15.60 ©Silberschatz, Korth and Sudarshan
 Deadlock Detection (Cont.)

Waits for z
Waits for z

Waits for x Waits for x

Waits for x
Waits for x
Waits for y
Waits for y Waits for y

Wait-for graph without a cycle Wait-for graph with a cycle

T17 waiting for T18 and T19 One more, T20 waiting for T19
T19 waiting for T18 T18,T19 and T20 are deadlocked
T18waiting for T20

Database System Concepts - 6th Edition 15.61 ©Silberschatz, Korth and Sudarshan
 Deadlock Recovery
● When deadlock is detected, actions : For the rollback
1. Selection of a victim -- determine which transaction (made a
victim) to rollback to break deadlock with minimum cost factors
a. How long the transaction has computed, and how much
longer the transaction will compute before it completes
b. How many data items used by the transaction
c. How many more data items needs for the completion
d. How many transactions will be involved in rollback

Database System Concepts - 6th Edition 15.62 ©Silberschatz, Korth and Sudarshan
 Deadlock Recovery
● When deadlock is detected, actions : For the rollback
1. Selection of a victim
2. Rollback -- determine how far to roll back transaction
4 Total rollback: Abort the transaction and then restart it
4 Partial rollback: More effective to roll back transaction only as
far as necessary to break deadlock requires to manage extra
information
3. Starvation -- if same transaction is always chosen as victim, not
allowing it to complete
4 Pick victim only for finite number of times and use number of
rollbacks as cost factor

Database System Concepts - 6th Edition 15.63 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● Till this, used individual data items as the synchronization unit
● Advantageous, if consider groups of several data items and treat them as
one individual synchronization unit
● If locks of all items of database is needed
4 Time consuming, if locking each item individually in the database
4 Better, if using a single lock for the entire database
● If locks of only few data item is needed
4 Not to lock entire database, otherwise concurrency will lost

Database System Concepts - 6th Edition 15.64 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● Allow data items to be of various sizes and define a hierarchy of data
granularities, where the small granularities are nested within larger ones
● Can be represented graphically as a tree (but don't confuse with
tree-locking protocol)
● When a transaction locks a node in the tree explicitly, it implicitly
locks all the node's descendents in the same mode

Database System Concepts - 6th Edition 15.65 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● If transaction Ti gets an explicit lock on file Fc in X-mode
● Then, it has an implicit lock in X-mode on all the records belonging
to that file
● Does not require to lock the individual records of Fc explicitly

Database System Concepts - 6th Edition 15.66 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● If Transaction Tj wishes to lock record rb6 of file Fb, since Ti has locked
Fb explicitly, it follows that rb6 is also locked (implicitly)
● Whether to lock or not, Tj must traverse the tree from the root to
record rb6. if any node in that path is locked in an incompatible
mode, then Tj must be delayed

Database System Concepts - 6th Edition 15.67 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● Granularity of locking (level in tree where locking is done)
● Fine granularity (lower in tree) The levels, starting from the coarsest
(top) level are
4 High concurrency Database, Area , File, Record
4 High locking overhead
● Coarse granularity (higher in tree)
4 Low locking overhead
4 Low concurrency

Database System Concepts - 6th Edition 15.68 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● If Transaction Tk wishes to lock the entire database, it is simply must
lock the root of the hierarchy
● But, Tk should not succeed in locking the root node, since Ti is
currently holding a lock on part of the tree (e.g. if, Fb)
● But, how does the system determine, if the root node can be locked?
4 Solution 1: Search the complete tree,
Not feasible
4 Solution 2:

Database System Concepts - 6th Edition 15.69 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity
● But, how does the system determine, if the root node can be locked?
● Solution 1: Search the complete tree, Not feasible
● Solution 2: Introduced New class of lock – INTENSION lock modes
4 If a node is locked in an intention mode, explicit locking is done at a
lower level of the tree
4 Intention locks are put on all the ancestors of a node before that node is
locked explicitly
4 So, the transaction does not need to search the entire tree to determine
whether it can lock

Database System Concepts - 6th Edition 15.70 ©Silberschatz, Korth and Sudarshan
 Intention Lock Modes
● In addition to S and X lock modes, there are three additional lock modes with
multiple granularity:
● intention-shared (IS): Indicates explicit locking at a lower level of the
tree but only with shared locks
● intention-exclusive (IX): Indicates explicit locking at a lower level with
exclusive or shared locks
● shared and intention-exclusive (SIX): The subtree rooted by that node is
locked explicitly in shared mode and explicit locking is being done at a
lower level with exclusive-mode locks
● intention locks allow a higher level node to be locked in S or X mode without
having to check all descendent nodes

Database System Concepts - 6th Edition 15.71 ©Silberschatz, Korth and Sudarshan
 Compatibility Matrix with Intention Lock Modes

● The compatibility matrix for all lock modes is:

Database System Concepts - 6th Edition 15.72 ©Silberschatz, Korth and Sudarshan
 Multiple Granularity Locking Scheme
● Transaction Ti can lock a node Q, using the following rules:
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, and may be locked in any mode.
3. A node Q can be locked by Ti in S or IS mode only if the parent of Q is
currently locked by Ti in either IX or IS mode.
4. A node Q can be locked by Ti in X, SIX, or IX mode only if the parent of Q
is currently locked by Ti in either IX or SIX mode.
5. Ti can lock a node only if it has not previously unlocked any node (that is, Ti
is two-phase).
6. Ti can unlock a node Q only if none of the children of Q are currently locked
by Ti.
● Observe that locks are acquired in root-to-leaf order, whereas they are released in
leaf-to-root order.
● Lock granularity escalation: in case there are too many locks at a particular
level, switch to higher granularity S or X lock

Database System Concepts - 6th Edition 15.73 ©Silberschatz, Korth and Sudarshan
 Intention Lock Modes
● If Transaction T21 reads a record ra2 in file Fa,
● Then T21 needs to lock the database area A1 and Fa in IS mode and
finally to lock ra2 in S mode
● If Transaction T22 modifies a record ra9 in file Fa,
● Then T22 needs to lock the database area A1 and Fa in IX mode and
finally to lock ra9 in X mode
● Concurrently allowed: T21 and T22

Database System Concepts - 6th Edition 15.74 ©Silberschatz, Korth and Sudarshan
 Intention Lock Modes
● If Transaction T21 reads a record ra2 in file Fa,
● Then T21 needs to lock the database area A1 and Fa in IS mode and
finally to lock ra2 in S mode
● If Transaction T23 reads all the records in file Fa,
● Then T23 needs to lock the database area A1 in IS mode and and
finally to lock Fa in S mode
● If Transaction T24 reads the entire database,
● Then T24 needs lock on the database S mode
● Not concurrently allowed: T21, T23
or T21, T24

Database System Concepts - 6th Edition 15.75 ©Silberschatz, Korth and Sudarshan
 Intention Lock Modes

● Enhances concurrency and reduces lock overhead

● Useful in applications, that include a mix of
● Short transactions that access only a few data items
● Long transactions that produce reports from an entire file or set
of files

Database System Concepts - 6th Edition 15.76 ©Silberschatz, Korth and Sudarshan
 View Serializability

Database System Concepts - 6th Edition 15.77 ©Silberschatz, Korth and Sudarshan
 Check for Conflict Serializability
T1 T2
R(A)
W(A)
R(A)
R(B)
W(A)
W(B)
R(B)
W(B)

YES, Conflict Serializable

Serial Schedule: <T1, T2>

Database System Concepts - 6th Edition 15.78 ©Silberschatz, Korth and Sudarshan
 View Serializability
● Let S1 and S2 be two schedules with the same set of transactions. S1
and S2 are view equivalent if the following three conditions are met,
for each data item A,
1. Schedules S1 and S2 are view equivalent, If Ti reads initial
value of A in S1, then Ti also reads initial value of A in S2
2. If Ti reads value of A written by Tj in S1, then Ti also reads
value of A written by Tj in S2
3. If Ti writes final value of A in S1, then Ti also writes final value
of A in S2

Database System Concepts - 6th Edition 15.79 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example: Check View Serializabiltiy: W3(Z), R2(X), W2(Y), R1(Z), W3(Y), W1(Y)
● To check for view serializability of a schedule, you must create all possible
combinations of the Transactions
● Here three transactions, then you need to check for these combinations:
< T1, T2, T3 >
< T1, T3, T2 >
< T2, T1, T3 >
< T2, T3, T1 >
< T3, T1, T2 >
< T3, T2, T1 >
● Now the schedule is view serializable if:
1. A Tx reads an initial data in a Schedule, the same Tx also should read the initial data
in one of the transaction combination.
4 Here, at least T2 must occur first, though it actually doesn’t matter also because no
one else writes X, so we still keep all our Tx combinations

Database System Concepts - 6th Edition 15.80 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example: W3(Z), R2(X), W2(Y), R1(Z), W3(Y), W1(Y)
2. A Tx reads a data after another Tx has written in a Schedule, the same Tx also
should read the data after another Tx has written it in one of the transaction
combination.
4 Now, this means that T1 must occur after T3 because T1 reads Z after T3
< T1, T2, T3 >
writes it. So we remove all where T1 is before T3
< T1, T3, T2 >
< T2, T1, T3 > – < T1, T2, T3 > < T2, T3, T1 >
< T2, T3, T1 > – < T1, T3, T2 > < T3, T1, T2 >
< T3, T1, T2 > < T3, T2, T1 >
< T3, T2, T1 > – < T2, T1, T3 >

Database System Concepts - 6th Edition 15.81 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example: W3(Z), R2(X), W2(Y), R1(Z), W3(Y), W1(Y)
3. A Tx writes the final value for a data in a Schedule, the same Tx should
also write the final data in one of the transaction combination.
4 Here, T1 must occur last after T3 or T2 because if not T3 or T2
will overwrites Y that T1 writes in our schedule. So we remove <
< T2, T3, T1 > T3, T1, T2 >
< T3, T1, T2 > < T2, T3, T1 >
< T3, T2, T1 > < T3, T2, T1 >

● So two combinations left satisfy the view serializability, they are:

< T2, T3, T1 >
< T3, T2, T1 >

Database System Concepts - 6th Edition 15.82 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example: R1(X),R2(Y),R2(Y),W2(X),W3(Y),R1(X)
1. A Tx reads an initial data in a Schedule, the same Tx also should read
the initial data in one of the transaction combination.
< T1, T2, T3 > 4 Here, at least T1 must occur first, before T2, so we remove
< T1, T3, T2 >
< T2, T1, T3 > 4 <T2, T1, T3>
< T1, T2, T3 >
< T2, T3, T1 > 4 <T2, T3, T1> < T1, T3, T2 >
< T3, T1, T2 > < T3, T1, T2 >
< T3, T2, T1 >
4 <T3, T2, T1>

Database System Concepts - 6th Edition 15.83 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example: R1(X),R2(Y),R2(Y),W2(X),W3(Y),R1(X)
2. A Tx reads a data after another Tx has written in a Schedule, the same Tx also
should read the data after another Tx has written it in one of the transaction
combination
4 T1 reads X after T2 writes, means that T2 should occur before T1
» But wait a minute, we’ve just said that T1 should occur before T2 on the
previous condition
» Because a cycle in the graph also caused
» Need T1 before T2 and at the same time, need T2 before T1
» Because of this, none of the combinations can satisfy these two
conditions, so it is not view serializable.

Database System Concepts - 6th Edition 15.84 ©Silberschatz, Korth and Sudarshan
 View Serializability (Cont.)
● Example:
●

● Conflict Serializable?
A A,B
T T T
1 2 3

B
● Conflict is NOT resolved, so it is NOT Conflict Serializable
● View Serializable?

● <T2, T1,T3>

● YES, view serializable schedule and schedule T2,T1,T3 is view

equivalent schedule for the given schedule

Database System Concepts - 6th Edition 15.85 ©Silberschatz, Korth and Sudarshan