DATABASE SYSTEM CONCEPTS (6th Edition)-Abraham Silberschatz

Chapter 15 : Concurrency Control

Biplab C. Debnath
Lecturer
Dept. of Computer Science and Engineering

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Review of the previous class

© Biplab C. Debnath CSE 301 Database 2 Lecturer, CSE

 Outline

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

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Lock-Based Protocols
● 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 the concurrency-control manager by
the programmer. Transaction can proceed only after request is
granted.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 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
● 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 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 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 The Two-Phase Locking Protocol

● This protocol 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).

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlocks
● 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlocks (Cont.)

● Two-phase locking does not ensure freedom from deadlocks.

● In addition to deadlocks, there is a possibility of starvation.
● Starvation occurs if the 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlocks (Cont.)
● The potential for deadlock exists in most locking protocols.
Deadlocks are a necessary evil.
● When a deadlock occurs there is a possibility of cascading
roll-backs.
● Cascading roll-back is possible under two-phase locking. To
avoid this, follow a modified protocol called strict two-phase
locking -- 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Implementation of Locking

● 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

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Lock Table
● Dark blue rectangles indicate granted
locks; light blue 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

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 The lock manager processes requests this way:

•When a lock request message arrives, it adds a record to the end of

the linked list for the data item, if the linked list is present. Otherwise it
creates a new linked list, containing only the record for the request.

It always grants a lock request on a data item that is not currently

locked. But if the transaction requests a lock on an item on which a
lock is currently held, the lock manager grants the request only if it is
compatible with the locks that are currently held, and all earlier
requests have been granted already. Otherwise the request has to
wait.
.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 • When the lock manager receives an unlock message from a
transaction, it deletes the record for that data item in the linked
list corresponding to that transaction. If it can, the lock manager
grants that request, and processes the record following it, if any,
similarly, and so on.

• If a transaction aborts, the lock manager deletes any waiting

request made by the transaction. Once the database system has
taken appropriate actions to undo the transaction (see Section
16.3), it releases all locks held by the aborted transaction

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock Handling

● 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 More Deadlock Prevention Strategies

● 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. (older means smaller timestamp) 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Returning to our example, with transactions T14, T15, and T16, if T14
requests a data item held by T15, then the data item will be preempted
from T15, and T15 will be rolled back. If T16 requests a data item held by
T15, then T16 will wait.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock prevention (Cont.)

● 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.
If the lock has not been granted within that time, the transaction
is rolled back and restarted,
– Thus, deadlocks are not possible
– simple to implement; but starvation is possible. Also difficult to
determine good value of the timeout interval.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock Detection

● 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.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock Detection (Cont.)

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

cycle cycle

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock Recovery

● When deadlock is detected :

– Selection of a victim: Some transaction will have to rolled
back (made a victim) to break deadlock. Select that
transaction as victim that will incur minimum cost.

✔ How long the transaction has computed, and how much longer the
transaction will compute before it completes its designated task?
✔ How many data items the transaction has used?
✔ How many more data items the transaction needs for it to
complete?
✔ How many transactions will be involved in the rollback?

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 Deadlock Recovery

– 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

❑ a transaction can be picked as a victim only a (small) finite

number of times. The most common solution is to include the
number of rollbacks in the cost factor.

© Biplab C. Debnath CSE 301 Database Lecturer, CSE

 What you have learn from this
lecture?

Discuss with your Learning Partner.

24
© Biplab C. Debnath CSE 301 Database Lecturer, CSE
 References

© Biplab C. Debnath CSE 301 Database Lecturer, CSE