Database Management System

Unit 9
Concurrency Control Techniques

Instructor
Indra Chaudhary
[email protected]
 DBMS: Syllabus
2

 Two-Phase Locking Techniques

 Timestamp Ordering
 Multversion Concurrency Control
 Validation (Optimistic) Techniques
 Snapshot Isolation Concurrency Control
 Concurrency Control
3

 A database must provide a mechanism that will ensure that all

possible schedules are
 either conflict or view serializable, and

 are recoverable and preferably cascadeless

 Concurrency control is the process of managing simultaneous

execution of transactions in a shared database, to ensure the
serializability of transactions.
 Concurrency Control (Cont.)
4

Purpose for using Concurrency:

 To apply Isolation through mutual exclusion between
conflicting transactions
 To resolve read-write and write-write conflict issues
 To preserve database consistency through constantly preserving
execution obstructions
 The system needs to control the interaction among the
concurrent transactions. This control is achieved using
concurrent-control schemes.
 Concurrency control helps to ensure serializability
 Lock-Based Protocols
5

 A lock is a mechanism to control concurrent access to a

data item
 Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read as well
as
written. X-lock is requested using lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is

requested using lock-S instruction.

 Lock requests are made to concurrency-control manager.
Transaction can proceed only after request is granted.
 Lock-Based Protocols (Cont.)
6

 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
 Any number of transactions can hold shared locks on an item,
 but if any transaction holds an 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. The lock is then granted.
 Lock-Based Protocols (Cont.)
7

 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 as above 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. Locking protocols restrict the set of possible
schedules.
 Pitfalls of Lock-Based Protocols
8
 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 executing lock-X(A) causes T3 to
wait for T4 to release its lock on A.
 Such a situation is called a deadlock.
 To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
 Pitfalls of Lock-Based Protocols (Cont.)
9

 The potential for deadlock exists in most locking

protocols. Deadlocks are a necessary evil.
 Starvation is also possible if concurrency control
manager is badly designed. For example:
 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.
 The same transaction is repeatedly rolled back due to
deadlocks.
 Concurrency control manager can be designed to
prevent starvation.
 The Two-Phase Locking Protocol
10

 This is a protocol which ensures conflict-serializable

schedules.
 Phase 1: Growing Phase
 transaction may obtain locks
 transaction may not release locks
 Phase 2: Shrinking Phase
 transaction may release locks
 transaction may not obtain locks
 The protocol assures serializability. It 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 Two-Phase Locking Protocol (Cont.)
11

 Two-phase locking does not ensure freedom from

deadlocks
 Cascading roll-back is possible under two-phase locking.
To avoid this, follow a modified protocol called strict
two-phase locking. Here a transaction must hold all its
exclusive locks till it commits/aborts.
 Rigorous two-phase locking is even stricter: here all
locks are held till commit/abort. In this protocol
transactions can be serialized in the order in which they
commit.
 The Two-Phase Locking Protocol (Cont.)
12

 There can be conflict serializable schedules that

cannot be obtained if two-phase locking is used.
 However, in the absence of extra information (e.g.,

ordering of access to data), two-phase locking is

needed for conflict serializability in the following
sense:
Given a transaction Ti that does not follow two-phase
locking, we can find a transaction Tj that uses two-
phase locking, and a schedule for Ti and Tj that is not
conflict serializable.
 Lock Conversions
13

 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.
 Implementation of Locking
14

 A lock manager can be implemented as a separate process to

which transactions send lock and unlock requests
 The lock manager replies to a lock request by sending a lock
grant messages (or a message asking the transaction to roll
back, in case of a deadlock)
 The requesting transaction waits until its request is answered
 The lock manager maintains a data-structure called a lock
table to record granted locks and pending requests
 The lock table is usually implemented as an in-memory hash
table indexed on the name of the data item being locked
 Lock Table
15
 Black rectangles indicate granted locks,
white ones indicate waiting requests
 Lock table also records the type of lock
granted or requested
 New request is added to the end of the
queue of requests for the data item, and
granted if it is compatible with all earlier
locks
 Unlock requests result in the request
being deleted, and later requests are
checked to see if they can now be granted
 If transaction aborts, all waiting or
granted requests of the transaction are
deleted
 lock manager may keep a list of locks
held by each transaction, to
implement this efficiently
 Deadlock Handling
16

 Consider the following two transactions:

T1: write (X) T2: write(Y)
write(Y) write(X)
 Schedule with deadlock
 Deadlock Handling
17

 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.
 Deadlock prevention protocols ensure that the system will
never enter into a deadlock state. Some prevention strategies :
 Require that each transaction locks all its data items before it begins
execution (predeclaration).
 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).
 More Deadlock Prevention Strategies
18

 Following schemes use transaction timestamps for the sake of

deadlock prevention alone.
 wait-die scheme — non-preemptive
 older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.
 a transaction may die several times before acquiring needed data item
 wound-wait scheme — preemptive
 older transaction wounds (forces rollback) of younger transaction
instead of waiting for it. Younger transactions may wait for older ones.
 may be fewer rollbacks than wait-die scheme.
 Deadlock prevention (Cont.)
19

 Both in wait-die and in wound-wait schemes, a rolled back

transactions is restarted with its original timestamp. Older
transactions thus have precedence over newer ones, and
starvation is hence avoided.
 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.
 thus deadlocks are not possible
 simple to implement; but starvation is possible. Also difficult to
determine good value of the timeout interval.
 Deadlock Detection
20

 Deadlocks can be described as a wait-for graph, which consists

of a pair G = (V,E),
 V is a set of vertices (all the transactions in the system)
 E is a set of edges; each element is an ordered pair Ti Tj.
 If Ti  Tj is in E, then there is a directed edge from Ti to Tj,
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. 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. Must invoke a deadlock-detection algorithm
periodically to look for cycles.
 Deadlock Detection (Cont.)
21

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

 Deadlock Recovery
22

 When deadlock is detected :

 Some transaction will have to rolled back (made a victim)
to break deadlock. Select that transaction as victim that
will incur minimum cost.
 Rollback -- determine how far to roll back transaction
 Total rollback: Abort the transaction and then restart it.
 More effective to roll back transaction only as far as necessary to
break deadlock.
 Starvation happens if same transaction is always chosen as
victim. Include the number of rollbacks in the cost factor to
avoid starvation
 Timestamp-Based Protocols
23

 Each transaction is issued a timestamp when it enters the system.

If an old transaction Ti has time-stamp TS(Ti), a new transaction
Tj is assigned time-stamp TS(Tj) such that TS(Ti) <TS(Tj).
 The protocol manages concurrent execution such that the time-
stamps determine the serializability order.
 In order to assure such behavior, the protocol maintains for each
data Q two timestamp values:
 W-timestamp(Q) is the largest time-stamp of any transaction that
executed write(Q) successfully.
 R-timestamp(Q) is the largest time-stamp of any transaction that executed
read(Q) successfully.
 Timestamp-Based Protocols (Cont.)
24

 The timestamp ordering protocol ensures that any

conflicting read and write operations are executed
in timestamp order.
 Suppose a transaction Ti issues a read(Q)
1. If TS(Ti) < W-timestamp(Q), then Ti needs to read a value
of Q that was already overwritten.
 Hence, the read operation is rejected, and Ti is rolled back.
2. If TS(Ti) W-timestamp(Q), then the read operation is
executed, and R-timestamp(Q) is set to max(R-
timestamp(Q), TS(Ti)).
 Timestamp-Based Protocols (Cont.)
25

 Suppose that transaction Ti issues write(Q).

1. If TS(Ti) < R-timestamp(Q), then the value of Q that Ti is producing
was needed previously, and the system assumed that that value would
never be produced.
 Hence, the write operation is rejected, and T is rolled back.
i

2. If TS(Ti) < W-timestamp(Q), then Ti is attempting to write an obsolete

value of Q.
 Hence, this write operation is rejected, and T is rolled back.
i

3. Otherwise, the write operation is executed, and W-timestamp(Q) is

set to TS(Ti).
 Example Use of the Protocol
26

 A partial schedule for several data items for transactions with

timestamps 1, 2, 3, 4, 5
 Correctness of Timestamp-Ordering Protocol
27

 The timestamp-ordering protocol guarantees serializability since all

the arcs in the precedence graph are of the form:

Thus, there will be no cycles in the precedence graph

 Timestamp protocol ensures freedom from deadlock as no
transaction ever waits.
 But the schedule may not be cascade-free, and may not even be
recoverable.
 Recoverability and Cascade Freedom
28

 Problem with timestamp-ordering protocol:

 Suppose Ti aborts, but Tj has read a data item written by Ti
 Then Tj must abort; if Tj had been allowed to commit earlier, the
schedule is not recoverable.
 Further, any transaction that has read a data item written by Tj must abort
 This can lead to cascading rollback --- that is, a chain of rollbacks
 Solution 1:
 A transaction is structured such that its writes are all performed at the
end of its processing
 All writes of a transaction form an atomic action; no transaction may
execute while a transaction is being written
 A transaction that aborts is restarted with a new timestamp
 Solution 2: Limited form of locking: wait for data to be committed
before reading it
 Solution 3: Use commit dependencies to ensure recoverability
 Thomas’ Write Rule
29

 Modified version of the timestamp-ordering protocol in which

obsolete write operations may be ignored under certain
circumstances.
 When Ti attempts to write data item Q, if TS(Ti) < W-timestamp(Q),
then Ti is attempting to write an obsolete value of {Q}.
 Rather than rolling back Ti as the timestamp ordering protocol would
have done, this {write} operation can be ignored.
 Otherwise this protocol is the same as the timestamp ordering
protocol.
 Thomas' Write Rule allows greater potential concurrency.
 Allows some view-serializable schedules that are not conflict-serializable.
 Read yourself
30

 Multversion Concurrency Control

 Validation (Optimistic) Techniques

 Snapshot Isolation Concurrency Control

31

Thank You