 Schedule :-

 A series of opera on from one transac on to another

transac on is known as schedule. It is used to preserve the
order of the opera on in each of the individual transac on.

1. Serial Schedule
The serial schedule is a type of schedule where one transac on is
executed completely before star ng another transac on. In the serial
schedule, when the first transac on completes its cycle, then the
next transac on is executed.
For example: Suppose there are two transac ons T1 and T2 which
have some opera ons. If it has no interleaving of opera ons, then
there are the following two possible outcomes:
1. Execute all the opera ons of T1 which was followed by all the
opera ons of T2.
2. Execute all the opera ons of T1 which was followed by all the
opera ons of T2.
o In the given (a) figure, Schedule A shows the serial schedule
where T1 followed by T2.
 o In the given (b) figure, Schedule B shows the serial schedule
where T2 followed by T1.
2. Non-serial Schedule
o If interleaving of opera ons is allowed, then there will be non-
serial schedule.
o It contains many possible orders in which the system can
execute the individual opera ons of the transac ons.
o In the given figure (c) and (d), Schedule C and Schedule D are
the non-serial schedules. It has interleaving of opera ons.
3. Serializable schedule
o The serializability of schedules is used to find non-serial
schedules that allow the transac on to execute concurrently
without interfering with one another.
o It iden fies which schedules are correct when execu ons of the
transac on have interleaving of their opera ons.
o A non-serial schedule will be serializable if its result is equal to
the result of its transac ons executed serially.
 here,
Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.
  Tes ng of Serializability
 Serializa on Graph is used to test the Serializability of a
schedule.
Assume a schedule S. For S, we construct a graph known as
precedence graph. This graph has a pair G = (V, E), where V consists a
set of ver ces, and E consists a set of edges. The set of ver ces is
used to contain all the transac ons par cipa ng in the schedule. The
set of edges is used to contain all edges Ti ->Tj for which one of the
three condi ons holds:
1. Create a node Ti → Tj if Ti executes write (Q) before Tj executes
read (Q).
2. Create a node Ti → Tj if Ti executes read (Q) before Tj executes
write (Q).
3. Create a node Ti → Tj if Ti executes write (Q) before Tj executes
write (Q).

o If a precedence graph contains a single edge Ti → Tj, then all

the instruc ons of Ti are executed before the first instruc on of
Tj is executed.
o If a precedence graph for schedule S contains a cycle, then S is
non-serializable. If the precedence graph has no cycle, then S is
known as serializable.
For example:
Explana on:
Read(A): In T1, no subsequent writes to A, so no new edges
Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges
Precedence graph for schedule S1:
The precedence graph for schedule S1 contains a cycle that's why
Schedule S1 is non-serializable.
Explana on:
Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): A is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges
Precedence graph for schedule S2:
The precedence graph for schedule S2 contains no cycle that's why
ScheduleS2 is serializable.

 Conflict Serializable Schedule :-

o A schedule is called conflict serializability if a er swapping of
non-conflic ng opera ons, it can transform into a serial
schedule.
o The schedule will be a conflict serializable if it is conflict
equivalent to a serial schedule.
 Conflic ng Opera ons :-
The two opera ons become conflic ng if all condi ons sa sfy:
1. Both belong to separate transac ons.
2. They have the same data item.
3. They contain at least one write opera on.
Example:
Swapping is possible only if S1 and S2 are logically equal.
Here, S1 = S2. That means it is non-conflict.

Here, S1 ≠ S2. That means it is conflict.

Conflict Equivalent
In the conflict equivalent, one can be transformed to another by
swapping non-conflic ng opera ons. In the given example, S2 is
conflict equivalent to S1 (S1 can be converted to S2 by swapping non-
conflic ng opera ons).
Two schedules are said to be conflict equivalent if and only if:
1. They contain the same set of the transac on.
2. If each pair of conflict opera ons are ordered in the same way.
Example:

Schedule S2 is a serial schedule because, in this, all opera ons of T1

are performed before star ng any opera on of T2. Schedule S1 can
be transformed into a serial schedule by swapping non-conflic ng
opera ons of S1.
A er swapping of non-conflict opera ons, the schedule S1
becomes:

T1 T2

Read(A)
Write(A)
 Read(B)
Write(B) Read(A)
Write(A)
Read(B)
Write(B)

Since, S1 is conflict serializable.

 View Serializability :-
o A schedule will view serializable if it is view equivalent to a
serial schedule.
o If a schedule is conflict serializable, then it will be view
serializable.
o The view serializable which does not conflict serializable
contains blind writes.
 View Equivalent :-
Two schedules S1 and S2 are said to be view equivalent if they sa sfy
the following condi ons:
1. Ini al Read
An ini al read of both schedules must be the same. Suppose two
schedule S1 and S2. In schedule S1, if a transac on T1 is reading the
data item A, then in S2, transac on T1 should also read A.
Above two schedules are view equivalent because Ini al read
opera on in S1 is done by T1 and in S2 it is also done by T1.
2. Updated Read
In schedule S1, if Ti is reading A which is updated by Tj then in S2
also, Ti should read A which is updated by Tj.
Adver sement

Above two schedules are not view equal because, in S1, T3 is reading
A updated by T2 and in S2, T3 is reading A updated by T1.
3. Final Write
A final write must be the same between both the schedules. In
schedule S1, if a transac on T1 updates A at last then in S2, final
writes opera ons should also be done by T1.

Above two schedules is view equal because Final write opera on in

S1 is done by T3 and in S2, the final write opera on is also done by
T3.
Example:

Schedule S
With 3 transac ons, the total number of possible schedule
1. = 3! = 6
2. S1 = <T1 T2 T3>
3. S2 = <T1 T3 T2>
4. S3 = <T2 T3 T1>
 5. S4 = <T2 T1 T3>
6. S5 = <T3 T1 T2>
7. S6 = <T3 T2 T1>
Taking first schedule S1:

Schedule S1
Step 1: final upda on on data items
In both schedules S and S1, there is no read except the ini al read
that's why we don't need to check that condi on.
Step 2: Ini al Read
The ini al read opera on in S is done by T1 and in S1, it is also done
by T1.
Step 3: Final Write
The final write opera on in S is done by T3 and in S1, it is also done
by T3. So, S and S1 are view Equivalent.
The first schedule S1 sa sfies all three condi ons, so we don't need
to check another schedule.
Hence, view equivalent serial schedule is:
  Recoverability of Schedule :-
Some mes a transac on may not execute completely due to a
so ware issue, system crash or hardware failure. In that case, the
failed transac on has to be rollback. But some other transac on may
also have used value produced by the failed transac on. So we also
have to rollback those transac ons.

The above table 1 shows a schedule which has two transac ons. T1
reads and writes the value of A and that value is read and wri en by
T2. T2 commits but later on, T1 fails. Due to the failure, we have to
rollback T1. T2 should also be rollback because it reads the value
wri en by T1, but T2 can't be rollback because it already commi ed.
So this type of schedule is known as irrecoverable schedule.
Irrecoverable schedule: The schedule will be irrecoverable if Tj reads
the updated value of Ti and Tj commi ed before Ti commit.
The above table 2 shows a schedule with two transac ons.
Transac on T1 reads and writes A, and that value is read and wri en
by transac on T2. But later on, T1 fails. Due to this, we have to
rollback T1. T2 should be rollback because T2 has read the value
wri en by T1. As it has not commi ed before T1 commits so we can
rollback transac on T2 as well. So it is recoverable with cascade
rollback.
Recoverable with cascading rollback: The schedule will be
recoverable with cascading rollback if Tj reads the updated value of
Ti. Commit of Tj is delayed ll commit of Ti.
The above Table 3 shows a schedule with two transac ons.
Transac on T1 reads and write A and commits, and that value is read
and wri en by T2. So this is a cascade less recoverable schedule.

 Failure Classifica on :-
 To find that where the problem has occurred, we generalize a
failure into the following categories:
1. Transac on failure
2. System crash
3. Disk failure
1. Transac on failure
The transac on failure occurs when it fails to execute or when it
reaches a point from where it can't go any further. If a few
transac on or process is hurt, then this is called as transac on
failure.
Reasons for a transac on failure could be -
1. Logical errors: If a transac on cannot complete due to
some code error or an internal error condi on, then the
logical error occurs.
2. Syntax error: It occurs where the DBMS itself terminates
an ac ve transac on because the database system is not
able to execute it. For example, The system aborts an
ac ve transac on, in case of deadlock or resource
unavailability.
2. System Crash
o System failure can occur due to power failure or other
hardware or so ware failure. Example: Opera ng system
error.
Fail-stop assump on: In the system crash, non-vola le storage is
assumed not to be corrupted.
3. Disk Failure
o It occurs where hard-disk drives or storage drives used to
fail frequently. It was a common problem in the early days
of technology evolu on.
o Disk failure occurs due to the forma on of bad sectors,
disk head crash, and unreachability to the disk or any
other failure, which destroy all or part of disk storage.

 Log-Based Recovery :-
o The log is a sequence of records. Log of each transac on is maintained in some s
storage so that if any failure occurs, then it can be recovered from there.
o If any opera on is performed on the database, then it will be recorded in the log
o But the process of storing the logs should be done before the actual transac on
in the database.
Let's assume there is a transac on to modify the City of a student. The following logs
for this transac on.
When the transac on is ini ated, then it writes 'start' log.
1. <Tn, Start>
When the transac on modifies the City from 'Noida' to 'Bangalore', then another log
to the file.
1. <Tn, City, 'Noida', 'Bangalore' >
When the transac on is finished, then it writes another log to indicate the end of the
transac on.
1. <Tn, Commit>
There are two approaches to modify the database:
1. Deferred database modifica on:
o The deferred modifica on technique occurs if the transac on does not modify t
database un l it has commi ed.
o In this method, all the logs are created and stored in the stable storage, and the
is updated when a transac on commits.

Recovery technique based on deferred update in a single user environment:

A recovery in a single-user environment is much easier than an environment in which
users are running transac ons simultaneously. To recover using the deferred update p
all commi ed and ini ated transac ons before the failure, follow these steps:
o In this, search forward through the log for the most recent checkpoint record. Th
last me the transac on data was sent to disk. All transac ons that were started
commi ed before the last checkpoint do not need to do anything because the d
already been saved.
o For any transac on T, for which the log contains both a [Start_transac on, T] rec
[Commit, T] records that appears in the log a er the last checkpoint. Database
 management uses the log records to redo the transac on and update the datab
new value in the transac on log.
o For any transac on T, in which the log only has a [Start_transac on, T] record bu
[Commit, T] record since the last checkpoint, nothing needs to be done because
database has never been updated.
To illustrate the concept of deferred update in a single user environment, consider an
involving two transac ons T1 and T2. Transac on T1 transfers Rs. 200 from account A
B and transac on T2 withdraws Rs. 100 from account C. The ini al balances of accoun
C are Rs. 1000, Rs. 1500 and Rs. 2000 respec vely. Suppose transac ons T1 and T2 ar
sequen ally with T1 followed by T2.

T1 T2

Read (A) Read I

A : = A - 200 C : = C - 100

Write (A) Write I

Read (B)

B := B + 200

Write (B)

The order in which these transac ons will be stored in system log will be discussed b
o When a transac on starts a transac on start record is wri en in the system log,
when transac on starts T1, a start record is wri en on the log. Similarly, when a
transac on T2 starts a start record is wri en in the system log.
o When a write opera on is performed, a write log record is wri en which contain
data given earlier. So when transac on T1 performs a Write (A) opera on, a writ
[Write, T1, A, 800] is wri en on the system log. One should note at this point, updates
wri en to disk. Similarly on execu on of Write (B) opera on by transac on T1 and Wr
opera on by transac on T2, appropriate write log records are wri en.
Adver sement
o When the transac on is commi ed, a commit record is wri en to the system log
transac on T1 is about to be commi ed, a transac on commit record is wri en
system log.
[Commit, T1]
All log records for the disk and transac on is commi ed.Similarly for transac on T2 is
be commi ed, a transac on commit record is wri en to the system log.
The full contents of the system log when these two transac ons (T1 and T2) are execu
sequence T1 and T2 are shown below:

Log Database

[Start_transac on, T1]

[Write , T1 , A, 800]

[Write , T1 , B, 1700]

[Commit, T1] A = 800

B = 1700

[Start_transac on, T2]

[Write , T2 , C, 1900]

[Commit , T2]
 C = 1900

Let's take an example where a system crashes before a transac on completes. So the
handles failure that result is loss of informa on using the log. In case of failure, the lo
examined star ng with the last entry ll the most recent checkpoint. All transac on s
transac on commit records before the abort record should be redone. The redo meth
performs all the writes to the database in the order they were wri en to the log. If th
has already been performed then the write opera on has no effect on the data item w
redone. This guarantees that all data items will be updated properly. All those transac
only contains start record but no commit record need to be restarted.
The figure below shows different situa ons when a system crash occurs:

The redo opera on must be mandatory in a deferred update, meaning running it repe
the same as running it only once. If the system fails during the recovery process, a suc
recovery a empts may redo some of the write opera ons that were already redone d
first recovery process, as if the recovery opera ons were restarted from the beginning
the redo write value is currently in the database, the result of a successful second rec
process on redo is the same as if the redo had succeeded the first me.
Condi on 1 Condi on 2 Condi on 3

[Start_transac on, T] [Start_transac on, T1] [Start_transac on, T

[Write , T1 , A, 800] [Write , T1 , A, 800] [Write , T1 , A, 800]

[Write , T1 , B, 1700] [Write , T1 , B, 1700] [Write , T1 , B, 1700

[abort, T1] [Commit, T1] [Commit, T1]

[Start_transac on, T2] [Start_transac on, T

crash [Write , T2 , C, 1900] [Write , T2 , C, 1900

[abort, T1] [Commit , T2]

[abort, T1]

crash

crash

Whenever recovery process

Whenever the recov
Whenever recovery process starts it finds that transac on
process starts it find
starts no redo ac on needs to T1 is already commi ed in the there are commi ed
be taken because no commit log. So opera on Redo for in the log for both
record appears in the log and transac on T1 must be transac ons T1 and
value of Account A and B performed and all data items
results in redo opera
remains same i.e. 1000 and updated by transac on T1 are
being performed for
1500 respec vely. copied into database. A = 800
and T2. Hence the v
and B = 1700. But the
data items A, B and
transac on T2 is not yet
 commi ed in the log so there 800, Rs. 1700 and Rs
is no need to redo the respec vely.
transac on T2. This
transac on T2 is deleted from
log and re-executed so value
of data item C = 2000.

Redo (T1)
No Redo Redo (T1) , Redo (T1
T2 must be re-executed

A = 1000, B = 1500, C = 2000 A = 800, B = 1700, C = 2000 A = 800, B =1700, C

2. Immediate database modifica on:

o The Immediate modifica on technique occurs if database modifica on occurs w
transac on is s ll ac ve.
o In this technique, the database is modified immediately a er every opera on. It
actual database modifica on.
Recovery based on immediate update:
Adver sement
In this technique, when a transac on issues an update command the database can be
immediately without wai ng for the transac on to read its commit point. The immed
update technique for recovery is also known as backward recovery because it tracks b
through the log and re-rolls all data items to their previous value every write opera o
transac on.
The change made by the update opera on is s ll updated in the log before the chang
recorded in the database using the write-ahead logging (WAL) technique so that we c
in case of failure.
Immediate update technique is divided into following two categories:
 o Undo / No redo technique: In this technique there is no needs to perform redo
because all changes are recorded in the database before the transac on is comm
o Undo / Redo recovery technique: In this technique the transac on is allowed to
all its changes before they are wri en to the database.
Undo/Redo recovery technique based on immediate update in a single user environ
In this, a transac on fails a er upda ng some changes in the database but before rea
commit point, the effect of its opera on on the database must be undone i.e. transac
be rolled back. Also if the transac on fails a er reaching its commit point, it is necess
the effect of the opera on of the commi ed transac ons from the log.
Follow the recovery steps using the immediate update process for all commi ed an
transac ons before the failure:
o In this, search forward through the log for the most recent checkpoint record. Th
last me the transac on data was sent to disk. All transac ons that were started
commi ed before the last checkpoint do not need to do anything because the d
already been saved.
o For any transac on T, the log contains both [Start_transac on, T] records and [C
records that appear in the log since the last checkpoint. Database management
records to redo the transac on and update the database using the new value. In
transac on log.
o For any transac on T, the log contains only [Start_transac on, T] records but no
T] records since the last checkpoint. Database management uses the log records
the opera ons using the old value in the log. To undo mul ple write opera ons
log we must precede in the reverse order in which they were wri en because th
transac on may have made mul ple changes to a single item.
To illustrate the concept of immediate update in a single user environment, consider t
example as discussed in Deferred Update which involves two transac ons T1 and T2.
Transac on T1 transfers Rs. 200 from account A to account B and transac on T2 withd
100 from account C, the ini al balances of accounts A, B and C are Rs. 1000, Rs. 1500
2000 respec vely. Suppose that transac ons T1 and T2 are executed sequen ally in T
and in different orders by T2, in which the actual output resul ng from the execu on
both the log and the database.

Log Database

[Start_transac on, T1]

[Write , T1 , A, 1000, 800]

A = 800

[Write , T1 , B, 1500, 1700]

B = 1700

[Commit, T1]

[Start_transac on, T2]

[Write , T2 , C, 2000, 1900]

C = 1900

[Commit , T2]

Now shall examine the different condi ons when a failure occurs.

Condi on 1 Condi on 2 Condi on 3

[Start_transac on, T] [Start_transac on, T1] [Start_transac on, T

[Write , T1 , A, 800] [Write , T1 , A, 800] [Write , T1 , A, 800]

[Write , T1 , B, 1700] [Write , T1 , B, 1700] [Write , T1 , B, 1700]

[abort, T1] [Commit, T1] [Commit, T1]

[Start_transac on, T2] [Start_transac on, T

crash [Write , T2 , C, 1900] [Write , T2 , C, 1900]

[abort, T1] [Commit , T2]

[abort, T1]

crash

crash

Whenever recovery process

starts, transac on T1 must be
redone and transac on T2
Whenever recovery
Whenever recovery process must be undone because
starts, both the tran
starts transac on T1 should both the [Start_transac on,
T1 and T2 should be
be undone because T1] and [Commit, T1] records
as both are having
corresponding to are present. So updates made
[Start_transac on, T
[Start_transac on, T1] record by transac on T1 are copied
commit records in th
no commit record is present to database but transac on
updates made by th
in the log. So old values are T2 has not yet commi ed in
should by them shou
copied to database. the log record so it must be
recorded in a databa
undone. So update made by
transac on T2 must be
revoked.

Redo (T1)
Undo (T1) Redo (T1) , Redo (T2
 Undo (T2)

A = 1000, B = 1500, C = 2000 A = 800, B = 1700, C = 2000 A = 800, B =1700, C

Undo/Redo recovery technique based on immediate update in mul user environme

In this, updates are made to the database immediately before the transac on is comm
when deadlock occurs in strict 2PL the transac on must be aborted and any changes
the transac on opera on must be rolled back.
The steps of recovery using immediate update in mul user environment where again
separate lists are created are the same as in case of single user environment. To expla
concept of immediate update in a mul user environment:
According to the algorithm for recovery using immediate update in a mul user envi
o In this, there is no need to undo or redo the write opera ons of transac ons T1
already commi ed before the last checkpoint.
o The write opera ons of transac ons T2 and T3 must be redone because both tra
reached the commit point a er the last checkpoint but before system crash i.e.
o The write opera ons of the transac on T4 should be undone because commit re
not wri en to the log.
Recovery using Log records
When the system is crashed, then the system consults the log to find which transac o
be undone and which need to be redone.
1. If the log contains the record <Ti, Start> and <Ti, Commit> or <Ti, Commit>, then
Transac on Ti needs to be redone.
2. If log contains record<Tn, Start> but does not contain the record either <Ti, comm
abort>, then the Transac on Ti needs to be undone.
  Checkpoint :-
In case of system failures, we check the logs to determine which of
the transac ons need to redone and those which need to be undone.
For this, we search the en re log to determine this informa on which
results in two major difficul es:
o It is very me consuming as we may have to search all log files.
In the worst case, the transac on may be stored at the end of
the log.
o Most of the transac ons which need to be redone have already
wri en their updates to the database.
For Example: In an online database system such as airline reserva on
system, hundreds of transac on could be handled per minute so for
such type of databases the log contains a large volume of
informa on.
Therefore, a scheme called checkpoint is used to limit the value of
log informa on that has to be handled and processed in case of
system failure.
Introduc on:
PauseNext
Mute
Current Time 0:32
/
Dura on 18:10
Loaded: 8.44%

Fullscreen
 o The checkpoint is a type of mechanism where all the previous
logs are removed from the system and permanently stored in
the storage disk.
o The checkpoint is like a bookmark. While the execu on of the
transac on, such checkpoints are marked, and the transac on
is executed then using the steps of the transac on, the log files
will be created.
o When it reaches to the checkpoint, then the transac on will be
updated into the database, and ll that point, the en re log file
will be removed from the file. Then the log file is updated with
the new step of transac on ll next checkpoint and so on.
o The checkpoint is used to declare a point before which the
DBMS was in the consistent state, and all transac ons were
commi ed.
When a system issues a checkpoint, the following opera ons are
performed:
o The log informa on from the buffers in the vola le storage is
copied to log on the stable storage.
o All database updates from the buffers in the vola le storage are
wri en to the disk.
o Write a checkpoint record to log on the disk so subsequent
database recovery coordinated with the checkpoint.
Recovery using Checkpoint
In the following manner, a recovery system recovers the database
from this failure:
o The recovery system reads log files from the end to start. It
reads log files from T4 to T1.
o Recovery system maintains two lists, a redo-list, and an undo-
list.
o The transac on is put into redo state if the recovery system
sees a log with <Tn, Start> and <Tn, Commit> or just <Tn,
Commit>. In the redo-list and their previous list, all the
transac ons are removed and then redone before saving their
logs.
o For example: In the log file, transac on T2 and T3 will have <Tn,
Start> and <Tn, Commit>. The T1 transac on will have only <Tn,
commit> in the log file. That's why the transac on is commi ed
a er the checkpoint is crossed. Hence it puts T1, T2 and T3
transac on into redo list.
  Deadlock in DBMS :-
A deadlock is a condi on where two or more transac ons are wai ng
indefinitely for one another to give up locks. Deadlock is said to be
one of the most feared complica ons in DBMS as no task ever gets
finished and is in wai ng state forever.
For example: In the student table, transac on T1 holds a lock on
some rows and needs to update some rows in the grade table.
Simultaneously, transac on T2 holds locks on some rows in the grade
table and needs to update the rows in the Student table held by
Transac on T1.
Now, the main problem arises. Now Transac on T1 is wai ng for T2
to release its lock and similarly, transac on T2 is wai ng for T1 to
release its lock. All ac vi es come to a halt state and remain at a
stands ll. It will remain in a stands ll un l the DBMS detects the
deadlock and aborts one of the transac ons.

Below is a list of condi ons necessary for a deadlock to occur:

Backward Skip 10sPlay VideoForward Skip 10s
o Circular Wai ng: It is when two or more transac ons wait each
other indefinitely for a lock held by the others to be released.
 o Par al Alloca on: When a transac on acquires some of the
required data items but not all the data items as they may be
exclusively locked by others.
o Non-Preemp ve scheduling: A data item that could be only
single transac on at a me.
o Mutual Exclusion: A data item can be locked exclusively by one
transac on at a me.
To avoid a deadlock atleast one of the above men oned necessary
condi ons should not occur.
Deadlock Avoidance
o When a database is stuck in a deadlock state, then it is be er to
avoid the database rather than abor ng or resta ng the
database. This is a waste of me and resource.
o Deadlock avoidance mechanism is used to detect any deadlock
situa on in advance. A method like "wait for graph" is used for
detec ng the deadlock situa on but this method is suitable
only for the smaller database. For the larger database, deadlock
preven on method can be used.
Deadlock Detec on
In a database, when a transac on waits indefinitely to obtain a lock,
then the DBMS should detect whether the transac on is involved in a
deadlock or not. The lock manager maintains a Wait for the graph to
detect the deadlock cycle in the database.
Wait for Graph
o This is the suitable method for deadlock detec on. In this
method, a graph is created based on the transac on and their
lock. If the created graph has a cycle or closed loop, then there
is a deadlock.
 o The wait for the graph is maintained by the system for every
transac on which is wai ng for some data held by the others.
The system keeps checking the graph if there is any cycle in the
graph.
The wait for a graph for the above scenario is shown below:

Deadlock Preven on
o Deadlock preven on method is suitable for a large database. If
the resources are allocated in such a way that deadlock never
occurs, then the deadlock can be prevented.
o The Database management system analyzes the opera ons of
the transac on whether they can create a deadlock situa on or
not. If they do, then the DBMS never allowed that transac on
to be executed.
Each transac on has unique iden fier which is called mestamp. It is
usually based on the state of the transac on and assigned once the
transac on is started. For example if the transac on T1 starts before
the transac on T2 then the mestamp corresponding to the
transac on T1 will be less than mestamp corresponding to
transac on T2. The mestamp decides whether a transac on should
wait or abort and rollback. Aborted transac on retain their
mestamps values and hence the seniority.
The following deadlock preven on schemes using mestamps have
been proposed.
o Wait-Die scheme
o Wound wait scheme
The significant disadvantage of both of these techniques is that some
transac ons are aborted and restarted unnecessarily even though
those transac ons never actually cause a deadlock.
Wait-Die scheme
In this scheme, if a transac on requests for a resource which is
already held with a conflic ng lock by another transac on then the
DBMS simply checks the mestamp of both transac ons. It allows
the older transac on to wait un l the resource is available for
execu on.
Let's assume there are two transac ons Ti and Tj and let TS(T) is a
mestamp of any transac on T. If T2 holds a lock by some other
transac on and T1 is reques ng for resources held by T2 then the
following ac ons are performed by DBMS:
1. Check if TS(Ti) < TS(Tj) - If Ti is the older transac on and Tj has
held some resource, then Ti is allowed to wait un l the data-
item is available for execu on. That means if the older
transac on is wai ng for a resource which is locked by the
younger transac on, then the older transac on is allowed to
wait for resource un l it is available.
2. Check if TS(Ti) < TS(Tj) - If Ti is older transac on and has held
some resource and if Tj is wai ng for it, then Tj is killed and
 restarted later with the random delay but with the same
mestamp.

If T1 is allowed to

Wait un l T2 is completed and it rele

t(T1) < t(T2)
acquire locks

t(T1) > t(T2) Abort and rolled back

In the above representa on, T1 is reques ng transac ons and T2 is

the transac on holding the lock on data item and t(Ti) is the
mestamp of the transac on Ti.
Consider an example in which transac ons having following
mestamps:

Transac on Timestamp

T1 5

T2 7

T3 9

If T1 request a data item is locked by transac on T2 then T1 has to

wait un l T2 completes and all locks acquired by it are released
because t(T1) < t(T2). On the other hand, if transac on T3 requests a
data item locked by transac on T2 and T3 has to abort and rollback
i.e. dies because t(T3) < t(T2).
Wound wait scheme
o In wound wait scheme, if the older transac on requests for a
resource which is held by the younger transac on, then older
transac on forces younger one to kill the transac on and
 release the resource. A er the minute delay, the younger
transac on is restarted but with the same mestamp.
o If the older transac on has held a resource which is requested
by the Younger transac on, then the younger transac on is
asked to wait un l older releases it.
o It is based on preemp ve technique.

If T1 is allowed to

t(T1) < t(T2) Wait

t(T1) > t(T2) Abort and rolled back (die)

In the above representa on, T1 is the reques ng transac ons and T2

is the transac on holding the lock on data item and t(Ti) is the
mestamp of the transac on Ti.
Consider an example in which transac ons having following
mestamps:

Transac on Timestamp

T1 5

T2 7

T3 9

If T1 request a data item is locked by transac on T2 then T1 has to

wait un l T2 completes and all locks acquired by it are released
because t(T1) < t(T2). On the other hand, if transac on T3 requests a
data item locked by transac on T2 then T3 has to wait because
t(T3) > t(T2).
Following are the differences between the Wait-Die scheme and
Wound wait scheme

Sr.no Wait-Die scheme Wound wait sche

It is based on non- It is based on pre

1.
preemp ve technique. technique.

An older transac on must In this scheme an

2. wait for younger one to transac on does
release their data items. younger transac

The number of ab
The number of aborts and
3. rollback transac
rollback is higher.
in this scheme.

As the transac o
A transac on T1 aborts and greater is the pro
rollback because retrieving a data
transac ons T2 contain the older would force
4. requested data items so T1 abor on of any y
can reissue the same transac ons that
transac on sequence of item it needs but
requests when started again. be aborted by tra
older then itself.

Deadlock Detec on and Recovery

In the deadlock detec on scheme, the deadlock detec on algorithm
checks the state of the system periodically whether the deadlock has
occurred or not, if the deadlock exists in the system tries to recover
from the deadlock.
In order to detect a deadlock the system must have the following
informa on:
 o The system should have informa on about the concurrent
group of transac ons.
o Informa on about the current alloca on of data items for
each transac on.
o It must have informa on about the current set of data
items that each transac on is wai ng for.
The system must provide an algorithm that uses this informa on i.e.
the informa on about the current alloca ons of data items to
examine whether a system has entered a deadlock state or not. If the
deadlock exists then the system a empts to recover from the
deadlock.
Recovery from Deadlock
If the wait for graph which is used for deadlock detec on contains a
deadlock situa on i.e. there exists cycles in it then those cycles
should be removed to recover from the deadlock. The most widely
used technique of recovering from a deadlock is to rollback one or
more transac ons ll the system no longer displays a deadlock
condi on.
The selec on of the transac ons to be rolled back is based on the
following delibera ons:
Selec on of vic m: There may be many transac ons which are
involved in a deadlock i..e deadlocked transac on. So to recover from
the deadlock some of the transac on should be rolled back, out of
the possible transac ons causing a deadlock. The one that is rolled
back is known as vic m transac on and the mechanism is known as
vic m elec on.
The transac ons to be rolled back are the one which has just started
or has not made many changes. Avoid selec ng transac ons that
have made many updates and have been running for a long me.
Rollback: Once the selec on of the transac on to be rolled back is
decided we should find out how far the current transac on should be
rolled back. One of the simplest solu on is the total rollback i.e.
abort the transac on and restart it. However, the transac on should
be rolled back to the extent required to break the deadlock. Also, the
addi onal informa on of the state of currently execu ng transac ons
should be maintained.
Starva on: To recover from the deadlock, we must ensure that the
same transac on should not be selected again and again as a vic m
to rollback. The transac on will never complete if the type of
situa on is not avoided. To avoid starva on, only a finite number of
mes a transac on should be picked up as a vic m.
A widely used solu on is to include the number of rollbacks of the
transac on that is selected as the vic m.
Mul ple choice ques ons on Deadlock in DBMS:
1. Which of the following condi on is not necessary for a deadlock
to occur?
o Circular Wai ng
o Par al Alloca on
o Preemp ve scheduling
o Mutual Exclusion
Answer:c
Explana on: Following is necessary condi ons for a deadlock occur:
o Circular Wai ng
o Par al Alloca on
o Non-Preemp ve scheduling
o Mutual Exclusion
2. A deadlock exists in the system if and only if the wai ng graph
contains ?
o Cycle
o Bi-direc on
o Direc on
o Rota on
Answer: c
Explana on: A deadlock exists in the system in the wai ng graph
contains cycle.
3. Which of the following is not a wait schemes in deadlock?
o Wait-Die Scheme
o Wound Wait Scheme
o Wait Scheme
Answer: c
Explana on: Following are the various wait schemes in deadlock:
o Wait-Die Scheme
o Wound Wait Scheme
4. A deadlock condi on is detected in advance by the ___
mechanism.
o Deadlock detec on
o Deadlock detec on
o Deadlock Avoidance
o Deadlock rehabilita on
Answer: c
Explana on:
A deadlock condi on is pre-detected by the deadlock avoidance
mechanism.

 DBMS Concurrency Control:-

Concurrency Control is the management procedure that is required
for controlling concurrent execu on of the opera ons that take place
on a database.
But before knowing about concurrency control, we should know
about concurrent execu on.
Concurrent Execu on in DBMS
o In a mul -user system, mul ple users can access and use the
same database at one me, which is known as the concurrent
execu on of the database. It means that the same database is
executed simultaneously on a mul -user system by different
users.
o While working on the database transac ons, there occurs the
requirement of using the database by mul ple users for
performing different opera ons, and in that case, concurrent
execu on of the database is performed.
o The thing is that the simultaneous execu on that is performed
should be done in an interleaved manner, and no opera on
should affect the other execu ng opera ons, thus maintaining
the consistency of the database. Thus, on making the
concurrent execu on of the transac on opera ons, there occur
several challenging problems that need to be solved.
Problems with Concurrent Execu on
In a database transac on, the two main opera ons
are READ and WRITE opera ons. So, there is a need to manage these
two opera ons in the concurrent execu on of the transac ons as if
these opera ons are not performed in an interleaved manner, and
the data may become inconsistent. So, the following problems occur
with the Concurrent Execu on of the opera ons:
Problem 1: Lost Update Problems (W - W Conflict)
The problem occurs when two different database transac ons
perform the read/write opera ons on the same database items in an
interleaved manner (i.e., concurrent execu on) that makes the values
of the items incorrect hence making the database inconsistent.
For example:
Consider the below diagram where two transac ons TX and TY, are
performed on the same account A where the balance of account A
is $300.

o At me t1, transac on TX reads the value of account A, i.e.,

$300 (only read).
 o At me t2, transac on TX deducts $50 from account A that
becomes $250 (only deducted and not updated/write).
o Alternately, at me t3, transac on TY reads the value of account
A that will be $300 only because TX didn't update the value yet.
o At me t4, transac on TY adds $100 to account A that becomes
$400 (only added but not updated/write).
o At me t6, transac on TX writes the value of account A that will
be updated as $250 only, as TY didn't update the value yet.
o Similarly, at me t7, transac on TY writes the values of account
A, so it will write as done at me t4 that will be $400. It means
the value wri en by TX is lost, i.e., $250 is lost.
Hence data becomes incorrect, and database sets to inconsistent.
Dirty Read Problems (W-R Conflict)
The dirty read problem occurs when one transac on updates an item
of the database, and somehow the transac on fails, and before the
data gets rollback, the updated database item is accessed by another
transac on. There comes the Read-Write Conflict between both
transac ons.
For example:
Consider two transac ons TX and TY in the below diagram
performing read/write opera ons on account A where the available
balance in account A is $300:
 o At me t1, transac on TX reads the value of account A, i.e.,
$300.
o At me t2, transac on TX adds $50 to account A that becomes
$350.
o At me t3, transac on TX writes the updated value in account A,
i.e., $350.
o Then at me t4, transac on TY reads account A that will be read
as $350.
o Then at me t5, transac on TX rollbacks due to server problem,
and the value changes back to $300 (as ini ally).
o But the value for account A remains $350 for transac on TY as
commi ed, which is the dirty read and therefore known as the
Dirty Read Problem.
Unrepeatable Read Problem (W-R Conflict)
Also known as Inconsistent Retrievals Problem that occurs when in a
transac on, two different values are read for the same database
item.
For example:
Consider two transac ons, TX and TY, performing the read/write
opera ons on account A, having an available balance = $300. The
diagram is shown below:

o At me t1, transac on TX reads the value from account A, i.e.,

$300.
o At me t2, transac on TY reads the value from account A, i.e.,
$300.
o At me t3, transac on TY updates the value of account A by
adding $100 to the available balance, and then it becomes
$400.
o At me t4, transac on TY writes the updated value, i.e., $400.
o A er that, at me t5, transac on TX reads the available value of
account A, and that will be read as $400.
o It means that within the same transac on TX, it reads two
different values of account A, i.e., $ 300 ini ally, and a er
upda on made by transac on TY, it reads $400. It is an
 unrepeatable read and is therefore known as the Unrepeatable
read problem.
Thus, in order to maintain consistency in the database and avoid such
problems that take place in concurrent execu on, management is
needed, and that is where the concept of Concurrency Control comes
into role.
Concurrency Control
Concurrency Control is the working concept that is required for
controlling and managing the concurrent execu on of database
opera ons and thus avoiding the inconsistencies in the database.
Thus, for maintaining the concurrency of the database, we have the
concurrency control protocols.
Concurrency Control Protocols
The concurrency control protocols ensure the atomicity, consistency,
isola on, durability and serializability of the concurrent execu on of
the database transac ons. Therefore, these protocols are categorized
as:
o Lock Based Concurrency Control Protocol
o Time Stamp Concurrency Control Protocol
o Valida on Based Concurrency Control Protocol
We will understand and discuss each protocol one by one in our next
sec ons.