SE (CS)

Spring Semester 2023

Database Management Systems

(CS-222)

Lecture #27-28
Concurrency Controls
(Deadlock Management, Intent Locking)

Dr Syed Zaffar Qasim

Assistant Professor (CIS)
1

Techniques for handling Deadlock

▪ There are three general techniques for handling
deadlock:
o timeouts,
o deadlock prevention, and
o deadlock detection and recovery.
▪ Prevention is commonly used if the probability that
the system would enter a deadlock state is
relatively high;
o otherwise, detection and recovery are more efficient.

CS-222: Database Management Systems 1

 DEADLOCK

▪ Since it is more difficult to prevent deadlock than

to use timeouts or detecting for deadlock and
breaking it when it occurs,
o systems generally avoid the deadlock
prevention method.
Timeouts
▪ A simple approach to deadlock avoidance is based
on lock timeouts.
▪ With this approach, a transaction that requests a
lock will wait for only a system-defined period of
time.
3

Timeouts
▪ If the lock has not been granted within this period,
the lock request times out.
▪ In this case, the DBMS assumes the transaction
may be deadlocked,
o even though it may not be, and
o it aborts and automatically restarts the
transaction.
▪ This is a very simple and practical solution to
deadlock avoidance and is used by several
commercial DBMSs.

CS-222: Database Management Systems 2

 Deadlock Prevention
▪ The second approach for preventing deadlocks
involves
o ordering transactions using timestamps
o using preemption and transaction rollbacks.
▪ Each transaction is assigned a unique timestamp.
▪ The system uses these timestamps only to decide
whether a transaction should wait or roll back.
▪ Two algorithms were proposed by Rosenkrantz.
▪ Locking is still used for concurrency control.
▪ If a transaction is rolled back, it retains its old
timestamp when restarted.
5

Deadlock Prevention
▪ The wait-die scheme is a non-preemptive technique.
o allows only an older transaction to wait for a
younger one,
o otherwise the transaction is aborted (dies) and
restarted with the same timestamp,
o so that eventually it will become the oldest active
transaction and will not die.
❖When Ti requests a data item currently held by Tj,
❖Ti is allowed to wait only if it has a timestamp
smaller than that of Tj (that is, Ti is older than Tj).
❖Otherwise, Ti is rolled back (dies).
6

CS-222: Database Management Systems 3

 Deadlock Prevention

o For example, suppose that transactions T1, T2,

and T3 have timestamps 5, 10, and 15,
respectively.
o If T2 requests a data item held by T3, then
❖ T2 will wait.
o If T3 requests a data item held by T2, then
❖ T3 will be rolled back.

Deadlock Prevention
▪ The wound-wait scheme is a preemptive technique.
o uses a symmetrical approach
o only a younger transaction can wait for an older one.
o If an older transaction requests a lock held by a
younger one, the younger one is aborted (wounded).
❖When transaction Ti requests a data item currently
held by Tj,
❖Ti is allowed to wait only if it has a timestamp
larger than that of Tj (that is, Ti is younger than Tj).
❖Otherwise, Tj is rolled back (Tj is wounded by Ti).
8

CS-222: Database Management Systems 4

 Deadlock Prevention

o Returning to our example of transactions T1,

T2, and T3 have timestamps 5, 10, and 15,
respectively.
o lf T2 requests a data item held by T3, then
o the data item will be preempted from T3, and
T3 will be rolled back.
o If T3 requests a data item held by T2, then
o T3 will wait.
9

Deadlock Prevention
▪ Whenever the system rollbacks transactions, it is
important to ensure that there is no starvation
o i.e., no transaction gets rolled back repeatedly
o and is never allowed to make progress.
▪ Both the DL prevention schemes avoid starvation:
o At any time, there is a transaction with the smallest
timestamp.
o This transaction cannot be required to roll back in
either scheme.
o Since timestamps always increase, and a transaction
that is rolled back repeatedly will eventually have
the smallest timestamp at which point it will not be
rolled back again.
10

CS-222: Database Management Systems 5

 Deadlock Prevention

▪ There are, however, significant differences in the

way that the two schemes operate.
▪ In the wait-die scheme, an older transaction must
wait for a younger one to release its data item.
▪ Thus, the older the transaction gets, the more it
tends to wait.
▪ By contrast, in the wound-wait scheme, an older
transaction never waits for a younger transaction.

11

Deadlock Prevention

▪ In the wait-die scheme,

o if a transaction Ti dies and is rolled back because
it requested a data item held by transaction Tj,
o then Ti may reissue the same sequence of
requests when it is restarted.
▪ If the data item is still held by Tj, then Ti will die
again.
▪ Thus, Ti may die several times before acquiring
the needed data item.

12

CS-222: Database Management Systems 6

 Deadlock Prevention

▪ Contrast this series of events with what happens in

the wound-wait scheme.
▪ Transaction Ti is wounded and rolled back because
Tj requested a data item that it holds.
▪ When Ti is restarted and requests the data item
now being held by Tj, Ti waits.
▪ Thus, there may be fewer rollbacks in the wound-
wait scheme.
▪ The major problem with both of these schemes is
that unnecessary rollbacks may occur.

13

Deadlock Detection
▪ The DBMS allows deadlock to occur but
recognizes occurrences of deadlock and breaks
them.
▪ Detecting the deadlock involves detecting a cycle
in the Wait-For-Graph
o (i.e. the graph of who is waiting for whom).
▪ The wait-for-graph (WFG) shows the transaction
dependencies:
o that is, transaction Ti is dependent on Tj
o if transaction Tj holds the lock on a data item that
Ti is waiting for.
14

CS-222: Database Management Systems 7

 Deadlock Detection

▪ The wait-for-graph is constructed as follows:-

1.Create a node for each transaction.
2.Create a directed edge Ti -> Tj, if transaction Ti is
waiting to lock an item that is currently locked
by Tj.
3.Deadlock exists if and only if the WFG contains
a cycle.

15

Deadlock Detection

▪ Since a cycle in the WFG is a necessary

and sufficient condition for deadlock to
exist,
othe deadlock detection algorithm
generates the wait-for-graph at regular
intervals and
oexamines it for a cycle.

16

CS-222: Database Management Systems 8

 Deadlock Detection
Transaction Data items locked by Data items transaction is
transaction waiting for
T1 X2 X3
T2 X3 X5
T3 X8 X3
T4 X7 X2, X5
T5 X5 X8

T1 T2

This graph has following

cycle:- T5
T3
T2 – T5 – T3 – T2

T4 17

Deadlock Detection

Exercise

Transaction Data items locked by Data items transaction

transaction is waiting for
T1 X2 X1, X3
T2 X3, X10 X7, X8
T3 X8 X4, X5
T4 X7 X1
T5 X1, X5 X3
T6 X4, X9 X6
T7 X6 X5

18

CS-222: Database Management Systems 9

 Deadlock Detection

▪ Breaking the deadlock involves choosing one of

the deadlocked transactions –
o i.e. one of the transactions in the cycle in the
graph – as the victim and
o rolling it back,
o thereby releasing its lock and so allowing
some other transaction to proceed.

19

Deadlock Detection
Choice of time interval
▪ The choice of time interval between executions
of the deadlock detection algorithm is
important.
o If the interval chosen is too small, deadlock
detection will add considerable overhead;
o if the interval is too large, deadlock may not be
detected for a long period.
▪ A dynamic detection algorithm could start with
an initial interval size. 20

CS-222: Database Management Systems 10

 Deadlock Detection
Choice of time interval

▪ Each time no deadlock is detected,

o the detection interval could be increased, for
example, to twice the previous interval, and
o every time deadlock is detected, the interval
could be reduced, for example, to half the
previous interval,
o subject to some upper and lower limits.

21

Recovery from Deadlock

▪ When a detection algorithm determines that a

deadlock exists, the system must recover from the
deadlock.
▪ The most common method is to rollback one or
more transactions to break the deadlock.
▪ Three actions need to be taken:-
1. Selection of a victim
2. Rollback transaction(s)
3. Avoid Starvation
22

CS-222: Database Management Systems 11

 Recovery from Deadlock

1. Selection of a victim: Given a set of deadlocked

transactions, we must determine which transaction
(or transactions) to rollback to break the deadlock.
o We should rollback those transactions that will
incur the minimum cost.
o Unfortunately, the term minimum cost is not a
precise one.
o Many factors may determine the cost of a
rollback.

23

Recovery from Deadlock

▪ Factors determining the cost of a rollback
o How long the transaction has computed and
how much longer the transaction will
compute before it completes its designated
task?
o How many data items the transaction has
used?
o How many more data items the transaction
needs for it to complete?
o How many transactions will be involved in
the rollback?
24

CS-222: Database Management Systems 12

 Recovery from Deadlock
2. Rollback: Once we have decided to rollback a
particular transaction, we must determine how
far this transaction should be rolled back.
o The simplest solution is a total rollback.
o However, it is more effective to roll back the
transaction only as far as necessary to break the
deadlock.
o Such partial rollback requires the system to
maintain additional information about the
sequence of lock requests / grants and updates
performed by the transaction.
25

Recovery from Deadlock

o The deadlock detection mechanism should

decide which locks the selected transaction
needs to release in order to break the
deadlock.
o The selected transaction must be rolled back
to the point where it obtained the first of
these locks, undoing all actions it took after
that point.

26

CS-222: Database Management Systems 13

 Recovery from Deadlock
o The recovery mechanism must be capable of
performing such partial rollbacks.
o Furthermore, the transactions must be capable of
resuming execution after a partial rollback.
3. Starvation: In a system where the selection of
victims is based primarily on cost factors,
o it may happen that the same transaction is
always picked as a victim.

27

Recovery from Deadlock

▪ As a result, this transaction never completes its

designated task, thus there is starvation.
▪ We must ensure that 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.

28

CS-222: Database Management Systems 14

 Locking Granularity
▪ Granularity: The size of data items chosen as the
unit of protection by a concurrency control
protocol.
▪ The database consists of a number of data items at
different degree of granularity.
▪ Typically a data item is chosen to be one of the
following, ranging from coarse to fine,
o The entire database
o A file (or table)
o A record
o A field value of a record
29

Locking Granularity

▪ Fine granularity refers to small item sizes and Coarse

granularity refers to large item sizes.
▪ Up to this point, we have been assuming that the
unit for locking purposes is the individual tuple.
▪ In principle, however, there is no reason why locks
should not be applied to larger or smaller units of
data,
o for example, an entire table or even the entire
database (or going to the opposite extreme),
o a specific component within a specific tuple.
30

CS-222: Database Management Systems 15

 Locking Granularity
▪ The size or granularity of the data item
o that can be locked in a single operation
o has a significant effect on the performance of the
concurrency control algorithm.
▪ Thus, the finer the granularity,
o the greater the concurrency
o but with higher overhead as more locking
information needs to be stored;
▪ The coarser the granularity,
o the lesser the concurrency
o but with lower overhead as fewer locks need to
be set and tested.
31

Locking Granularity

▪ For example, if a transaction has an X lock on an

entire relation,
o there is no need to set X locks on individual
tuples within that relation;
o on the other hand, no concurrent transaction will
be able to obtain any locks on that relation, or
o on tuples within that relation, at all.
▪ The best item size depends upon the nature of the
transactions.

32

CS-222: Database Management Systems 16

 Locking Granularity
▪ Consider a transaction that updates few records of
a relation (e.g. less than 10%).
▪ The concurrency control algorithm might allow the
transaction to lock only those records, in which
case the granule size for locking is a single record.
▪ On the other hand, if a transaction updates 90% of
the records in a file,
o then it would be more efficient to allow it to lock
the entire file
o rather than to force it to lock each record
separately.
33

Locking Granularity
▪ A transaction might lock the entire database, in
which case the granule size is the entire database.
▪ However this granularity would prevent any other
transactions from executing until the lock is
released.
▪ This would clearly be undesirable.
▪ Ideally, the DBMS should support mixed
granularity with data item, record, and file level
locking.

34

CS-222: Database Management Systems 17

 Locking Granularity

▪ Suppose some transaction T does in fact

request an X lock on some relation R.
▪ On receipt of T’s request,
o the system must be able to tell whether any
other transaction already has a lock on any
tuple of R, for if it does,
o then T’s request cannot be granted at this
time.
▪ How can the system detect such a conflict?
35

Locking Granularity

▪ It is obviously undesirable to examine every

tuple in R
o to see whether any of them is locked by any
of other transaction, or
o to have to examine every existing lock to see
whether any of them is for a tuple in R.
▪ Instead, we introduce another protocol,
o the intent locking protocol.

36

CS-222: Database Management Systems 18

 Intent Locking

▪ According to this protocol,

o no transaction is allowed to acquire a lock on a
tuple
o before first acquiring an intent lock on the
relation that contains it.
▪ Conflict detection in the example then becomes a
comparatively simple matter
o of seeing whether any transaction has a
conflicting lock at the relation level.
37

Intent Locking
▪ Now, we have already implied that X and S locks
make sense for whole relation as well as for
individual tuples.
▪ We now introduce three new kinds of locks, called
intent locks, that also make sense for relations, but
not for individual tuples.
▪ The new kinds of locks are called
o intent shared (IS),
o intent exclusive (IX) and
o shared intent exclusive (SIX) locks.
38

CS-222: Database Management Systems 19

 Intent Locking

▪ They can be defined informally as follows

1. IS: T intends to set S locks on individual tuples in
R, in order to guarantee the stability of those
tuples while they are being processed.
2. IX: T intends to set X locks on individual tuples
in R, in order to guarantee the stability of those
tuples while they are being updated.
3. S: T can tolerate concurrent readers, but not
concurrent updaters, in R.
o T itself will not update any tuples in R.
39

INTENT LOCKING

4. SIX: Combines S and IX;

o i.e. T can tolerate concurrent readers but not
concurrent updaters, in R,
o plus T might update individual tuples in R and
will therefore set X locks on those tuples.
5. X: T cannot tolerate any concurrent access to R at all;
o T itself might or might not update individual
tuples in R.

40

CS-222: Database Management Systems 20

 INTENT LOCKING

▪ Here now is a more precise statement of the intent

locking protocol:
1. Before a given transaction can acquire an S lock
on a given tuple,
o it must first acquire an IS or stronger lock on
the relation containing that tuple;
2. Before a given transaction can acquire an X lock
on a given tuple,
o it must first acquire an IX or stronger lock on
the relation containing that tuple.

41

INTENT LOCKING

Lock Precedence Graph

42

CS-222: Database Management Systems 21

 INTENT LOCKING
▪ The notion of relative lock strength can be explained as
follows.
▪ Refer to the precedence graph, we say that lock type L2 is
stronger i.e. higher in the graph than lock type L1, iff,
o whenever there is an N (conflict) in L1’s column in the
compatibility matrix for a given row,
o there is also an N in L2’s column for that same row.

43

INTENT LOCKING
▪ Note that a lock request that fails for a given lock type
will certainly fail for a stronger lock type
o and this fact implies that it is always safe to use a
lock type that is stronger than strictly necessary.
▪ Note too that neither of S and IX is stronger than the
other.

44

CS-222: Database Management Systems 22

 INTENT LOCKING

▪ It is worth pointing out that, in practice, the

relation level locks required by the intent locking
protocol will usually be acquired implicitly.
▪ For a read-only transaction, for example, the
system will probably acquire an IS lock implicitly
on every relation the transaction accesses.
▪ For an update transaction, it will probably acquire
IX locks instead.

45

INTENT LOCKING

▪ But the system will probably also have to provide

an explicit LOCK statement of some kind
o in order to allow transactions to acquire S, X or
SIX locks
o at the relation level if they want them.
E.g. LOCK Tablename
▪ Such a statement is supported by DB2, for example
(though for S and X locks only, not SIX locks).
46

CS-222: Database Management Systems 23

 INTENT LOCKING
▪ Lock escalation, which is implemented in many systems
o represents an attempt to balance the conflicting
requirements of
o high concurrency and low lock management overhead.
▪ Some systems automatically upgrade locks from record
to file
o if a particular transaction is locking more than a
certain percentage of the records in the file.
▪ However, escalating the granularity from field or
record to file may increase the likelihood of deadlock
occurring.

47

INTENT LOCKING

▪ The basic idea is that when the system reaches

some predefined threshold,
o it automatically replaces a set of fine-granularity
locks by a single coarse-granularity lock
o for example, by trading in a set of individual
tuple level S locks and
o converting the IS lock on the containing relation
to an S lock.
▪ This technique seems to work well in practice.

48

CS-222: Database Management Systems 24