Click on Subject/Paper under Semester to

enter. Environmental
Professional English Sciences
Professional and Sustainability -
English - I - - II - HS3252 Discrete GE3451
HS3152
Mathematics
Statistics and Theory of Computation
- MA3354
Numerical - CS3452
Matrices and
Methods - MA3251
Calculus Digital Principles
and Computer Artificial
- MA3151

Semester
Engineering Intelligence and
Semester

Organization
Semester

Graphics Machine Learning

Semester

- CS3351
Engineering - CS3491
Physics - PH3151 - GE3251
Foundation of Data
Physics for Science - CS3352 Database Management

4th
System - CS3492
2nd
1st

Engineering Information
3rd

Chemistry Science
Data Structure -
- CY3151 - PH3256 CS3301 Algorithms - CS3401
Basic Electrical and
Electronics Object Oriented Introduction to
Problem Solving Engineering Operating
Programming -
and Python - BE3251 Systems - CS3451
CS3391
Programming -
GE3151 Programming in C
- CS3251

Computer
Networks - Object Oriented
CS3591 Software
Engineering
- CCS356 Human Values and
Compiler Design - Ethics - GE3791
CS3501 Embedded
Semester

Semester

Systems and IoT - Open Elective 2

Cryptography CS3691
Semester

Project Work /
Semester

and Cyber
Security - Open Elective 3 Intership
CB3491 Open
Open Elective 4
5th

7th

Distributed Elective-1
8th

Computing
6th

Management
- CS3551 Elective-3
Elective
Elective 1 Elective-4

Elective 2 Elective-5

Elective-6
 All Computer Engg [ B.E., M.E., ] (Click on Subjects to
Subjects - enter)

Programming in C Computer Operating Systems

Networks
Programming and Data Programming and Problem Solving and
Structures I Data Python
Structure II Programming
Database Management Computer Analog and Digital
Systems Architecture Communication
Design and Analysis of Microprocessors and Object Oriented
Algorithms Microcontrollers Analysis
and Design
Software Engineering Discrete Internet Programming
Mathematics
Theory of Computation Computer Graphics Distributed Systems
Mobile Computing Compiler Design Digital Signal
Processing
Artificial Intelligence Software Testing Grid and Cloud
Computing
Data Ware Housing and Cryptography and Resource
Data Mining Network Security Management
Techniques
Service Oriented Embedded and Real Multi - Core
Architecture Time Systems Architectures and
Programming
Probability and Queueing Physics for Transforms and
Theory Information Partial Differential
Science Equations
Technical English Engineering Engineering Chemistry
Physics
 Engineering Graphics Total Quality Professional Ethics in
Management Engineering
Basic Electrical and Problem Solving Environmental Science
Electronics and and Python and Engineering
Measurement Engineering Programming
 www.BrainKart.
com
CS8492 DATABASE MANAGEMENT SYSTEMS

UNIT III

TRANSACTIONS

Transaction Concepts – ACID Properties – Schedules – Serializability – Concurrency Control –

Need for Concurrency – Locking Protocols – Two Phase Locking – Deadlock – Transaction

Recovery – Save Points – Isolation Levels – SQL Facilities for Concurrency and Recovery.

https://play.google.com/store/apps/details? Page: 1 / 30
 www.BrainKart.
com

UNIT - 3
TRANSACTIONS

TRANSACTION CONCEPTS
Transaction
• Collection of operations that form a single logical unit of work is called transaction.
• Transaction is executed as a single unit. If the database was in consistent state before a
transaction, then after execution of the transaction also, the database must be in a
consistent.
Process of Transaction
The transaction is executed as a series of reads and writes of database objects, which are
explained below:

(i) Read Operation(READ(X))

To read a database object, it is first brought into main memory (Local Buffer) from
disk(database), and then its value is copied into a program.

(ii) Write Operation (WRITE(X))

To write a database object, an in-memory copy of the object is first modified and then
written to disk

ACID PROPERTIES
Transaction Properties
There are four important properties of transaction that a DBMS must ensure to maintain
data in the case of concurrent access and system failures. These are:

Atomicity: (all or nothing)

A transaction is said to be atomic if a transaction always executes all its actions in one
step or not executes any actions at all It means either all or none of the transactions operations are
performed.

Consistency: (No violation of integrity constraints)

A transaction must preserve the consistency of a database after the execution. The DBMS
assumes that this property holds for each transaction. Ensuring this property of a transaction is
the responsibility of the user.

Isolation: (concurrent changes invisibles)

The transactions must behave as if they are executed in isolation. It means that if several
transactions are executed concurrently the results must be same as if they were executed serially
in some order. The data used during the execution of a transaction cannot be used by a second
transaction until the first one is completed.

https://play.google.com/store/apps/details? Page: 2 / 30
 www.BrainKart.
com

Durability: (committed update persist)

The effect of completed or committed transactions should persist even after a crash. It
means once a transaction commits, the system must guarantee that the result of its operations will
never be lost, in spite of subsequent failures.
The acronym ACID is sometimes used to refer above four properties of transaction that
we have presented here: Atomicity, Consistency, Isolation, and Durability.

Atomicity

Suppose that, just prior to execution of transaction Ti the values of account A and B are
Rs.I000 and Rs.2000.

Now, suppose that during the execution of Ti, a power failure has occurred that prevented
the Ti to complete successfully. The point of failure may be after the completion Write (A,a) and
before Write(B,b). It means that the changes in A are performed but not in B. Thus the values of
account A and Bare Rs.950 and Rs.2000 respectively. We have lost Rs.50 as a result 'of this
failure.

Now, our database is in inconsistent state. The reason for this inconsistent state is that our
transaction is completed partially and we save the changes of uncommitted transaction. So, in
order to get the consistent state, database must be restored to its original values i.e. A to Rs.I000
and B to Rs.2000, this leads to the concept of atomicity of transaction. It means that in order to
maintain the consistency of database, either all or none of transaction's operations are performed.

In order to maintain atomicity of transaction, the database system keeps track of the old
values of any write and if the transaction does not complete its execution, the old values are
restored to make it appear as the transaction never executed.

Consistency

The consistency requirement here is that the sum of A and B must be unchanged by the
execution of the transaction. Without the consistency requirement, money could be created or
destroyed by the transaction. It can. be verified easily that, if the database is consistent before an
execution of the transaction, the database remains consistent after the execution of the
transaction.
Ensuring consistency for an individual transaction is the responsibility of the application
programmer who codes the transaction.

Isolation

If several transactions are executed concurrently (or in parallel), then each transaction
must behave as if it was executed in isolation. It means that concurrent execution does not result
an inconsistent state.

Durability

Once the execution of the transaction completes successfully, and the user who initiated
the transaction has been notified that the transfer of funds has taken place, it must be the case that
no system failure will result in a loss of data corresponding to this transfer of funds.

https://play.google.com/store/apps/details? Page: 3 / 30
 www.BrainKart.
com

The durability property guarantees that, once a transaction completes successfully all the
updates that it carried out on the database persist, even if there is a system failure after the
transaction completes execution. Ensuring durability is the responsibility of a component of the
database system called the recovery-management component.

States of Transaction

The state diagram corresponding to a transaction is shown in Figure.

A transaction must be in one of the following states:

Fig 3.1 Transaction

States

Active: the initial state, the transaction stays in this state while it is
executing.
Partially committed: after the final statement has been executed.
➢ Failed: when the normal execution can no longer proceed.
➢ Aborted: after the transaction has been rolled back and the database has been restored to
its state prior to the start of the transaction.
➢ Committed: after successful completion.

SCHEDULES

Schedules (Histories) of Transaction

A Schedule (or history) S of n transaction T1, T2…Tn is an ordering of the operations of

the transactions subject to the constraint that for each transaction T i that participates in S the
operations of Ti in S must appear in the same order in which they occur in Ti.

https://play.google.com/store/apps/details? Page: 4 / 30
 www.BrainKart.
com

Conflict Schedule
Two operations in a schedule are said to conflict if they satisfy the following three
condition
• they belong to different transactions
• they access the same item X
• atleast one of the operations is a write – item (X)

Complete Schedule

A schedule S of n transactions T 1, T2…. Tn is said to be a complete schedule if the

following conditions hold
1. The operation in S are exactly those operations in T 1, T2, ….Tn, including a
commit or abort operation as the last operation for each transaction in the
schedule.
2. For any pair of operations from the same transaction T i, their order of appearance
in S is the same as their order of appearance in Ti.
3. For any two conflicting operations, one of the two must occur before the other in
the schedule.

Recoverability

If a transaction Ti fails, we need to undo the effect of this transaction to ensure the
atomicity property of the transaction. In a system that allows concurrent execution, it is necessary
to ensure that any transaction Tj that is dependent on Ti is also aborted.
To achieve this surety, we need to place restrictions on the type of schedules permitted in
the system.
Types of schedules that are acceptable from the view point of recovery from transaction
failure are:
1. Recoverable schedules
2. Cascadeless (non-cascading) schedules
3. Strict schedules.

1. Recoverable Schedules

A recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj
reads a data item previously written by Ti, the commit operation of Ti appears before the commit
operation of Tj.
In T9 is a transaction that performs only one instruction read (A). Suppose that the system
allows T9 to commit immediately after executing the read (A) instruction. Thus, T9 commits
before T8 does.

https://play.google.com/store/apps/details? Page: 5 / 30
 www.BrainKart.
com

T8 T9
read (A)
write (A)
read (A)

read (B)
Schedule-1
• Suppose that T8 fails before it commits. Since T9 has read the value of data item A written by
T8, we must abort T9 to ensure transaction atomicity. However T9 has already committed and
cannot be aborted. Thus it is impossible to recover correctly from the failure of T8.
• Schedule 11 is an example of non-recoverable schedule, which should not be allowed. Most
database system requires that all schedules be recoverable.
• A recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj
reads a data item previously written by Ti, the commit operation of Ti appears before the
commit operation of Tj.

3. Cascadeless Schedules

Even if a schedule is recoverable, to recover correctly from the failure of a transaction Ti,
we may have to roll back several transactions. Such situations occur if transactions have read
data written by Ti.
T10 T11 T11
read (A)
read (B)
write (A)
read (A)
write (A)
read (A)
Schedule-2
• Transaction T10 writes a value of A that is read by transaction T11. Transaction T11 writes a
value of A that is read by transaction T12. Suppose that, at this point, T10 fails. T10 must be
rolled back. Since T11 is dependent on T10, T11 must be rolled back.
• This phenomenon, in which a single transaction failure leads to a series of transaction roll
backs, is called cascading rollback.
• Cascading rollback is undesirable, since it leads to the undoing of a significant amount of
work.
• Therefore schedules with cascading rollbacks are undesirable. Schedules should not contain
cascading schedules are called cascadeless schedules.
• A cascadeless schedule is one where, for each pair of transactions Ti and Tj such that Tj
reads a data item previously written by Ti, the commit operation of Ti appears before the read
operation of Tj.

https://play.google.com/store/apps/details? Page: 6 / 30
 www.BrainKart.
com

Strict Schedules

This is a more restrictive schedule than the recoverable schedules and non cascading
schedules. In this schedule, transactions cannot read or write a data item ‘X’ until the last
transaction that wrote the data item ‘X’ has committed or aborted. Strict schedules simplify the
recovery process. In this, the process of undoing a write operation of an aborted transaction is
easy.

SERIALIZABILITY

Introduction
A schedule where the operations of each transaction are executed consecutively without
any other interference from other transactions is called serial schedule. Here the transactions are
performed in the serial order.
A non-serial schedule is a schedule where the operations from a group of concurrent
transactions are interleaved.
The objective of serializability is to find non-serial schedules that allow transactions to
executive concurrently without interfering with one another and thereby producing a database
state that could be produced by a serial execution.
A non-serial schedule is said to be serializable, if it produces the same results as some
serial execution of the transactions.

Types of Serializability
(1) Conflict serializability
(2) View serializability.

1. Conflict Serializability
Let us consider a schedule S in which there are two consecutive instructions Ii and Ij
of transactions Ti and Tj respectively (i j). If Ii and Ij refer to different data items, then we can
swap Ii and Ij without affecting the results of any instruction in the schedule. However, if Ii and Ij
refer to the same data item Q, then the order of the two steps may matter. Since we are dealing
with only read and write instructions, there are four cases that we need to consider.
1. Ii = read (Q), Ij = read (Q). The order Ii and Ij does not matter, since the same
value of Q is read by Ti and Tj regardless of the order.
2. Ii = read (Q), Ij = write (Q). If Ii comes before Ij, then Ti does not read the value
of Q that is written by Tj in instruction Ij. If Ij comes beore Ii, then Ti reads the
value of Q that is written by Tj. Thus the order of Ii and Ij matters.
3. Ii = write (Q), Ij = read (Q). The order of Ii and Ij matters, reason is same as
previous case.
4. Ii = write (Q), Ij = write (Q). Since both the instructions are write operations, the
order of these instructions does not affect either Ti or Tj. However the value
obtained by the next read (Q) instruction S is affected, since the result of only the
latter of the two write instructions is preserved in the database. If there is no other

https://play.google.com/store/apps/details? Page: 7 / 30
 www.BrainKart.
com

write (Q) instruction after Ii and Ij in S then the order of Ii and Ij directly affects the
final or Q in the database state that results from schedule S.
Thus, only in the case where both Ii and Ij are read instructions does the order of
their execution does not matter.
We say that Ii and Ij conflict if they are operations by different transactions on the same
data item and at least one of these instructions is a write operation.

Consider following schedule 3.

T1 T2
read (A)
write (A)
read (A)
write (A)
read (B)
write (B)
read (B)
write (B)

Schedule-3 - showing only the read and write operations

The write (A) of T1 conflicts with read (A) of T2. However, write (A) of T2 does not
conflict with read (B) of T1, because, the two instructions access different data items.
Because of no conflict, we can swap write (A) and read (B) instructions to generate a new
schedule 5 as shown in Fig Regardless of initial system state, schedule 3 and 5 generates same
result.
T1 T2
read (A)
write (A)
read (A)

read (B)

write (A)

write (B)
read (B)
write (B)

Schedule 5-schedule 3 after swapping a pair of instructions

We can continue to swap non-conflicting instructions:
❖ Swap the read (B) instruction of T1 with read (A) instruction of T2.
❖ Swap the write (B) instruction of T1 with write (A) instruction of T2.
❖ Swap the write (B) instruction of T1 with the read (A) instruction of T2.

The final result of these swaps - is shown below, which is serial schedule.

https://play.google.com/store/apps/details? Page: 8 / 30
 www.BrainKart.
com

T1 T2
read (A)
write (A)
read (B)
write (B)

read (A)
write (A)
read (B)
write (B)

Schedule 6 serial schedule that is equivalent to schedule 3

If a schedule S can be transformed into a schedule S1 by a series of swaps of non-

conflicting instructions, we say that S and S1 are conflict equivalent.

The concept of conflict equivalence loads to the concept of conflict serializability. We say
that a schedule S is conflict serializable, if it is conflict equivalent to a serial schedule. Thus
schedule 3 is conflict serializable, since it is conflict equivalent to the serial schedule 1.

Consider schedule 7 of Fig.5.9. It consists of two transactions T3 and T4. This schedule is
not conflict serializable, since it is not equivalent to either the serial schedule <T3, T4> or the
read
serial schedule <T4, T3>.
(Q)
T3 T4

write (Q)

write (Q)
Schedule 7
2. View Serializability
Consider two schedules S and S1, where the same set of transactions participates in both
the schedules. The schedule S and S1 are said to be view equivalent if three conditions are met:
1. For each data item Q, if transaction Ti reads the initial value of Q in schedule
S, then transaction Ti must in schedule S1, also read the initial value of Q.
2. For each data item Q, if transaction Ti executes read (Q) in schedule S, and
if that value was produced by a write (Q) operation executed by transaction Tj,
then the read (Q) operation of transaction Ti must, in schedule S1, also read the
value of Q that was produced by the same write (Q) operation of transaction Tj.
3. For each data item Q, the transaction (if any) that performs the final write (Q)
operation in schedule S must perform the final write (Q) operation in schedule S1.

The concept of view equivalence leads to the concept of view serializability. We say that
a schedule S is view serializable, if it is view equivalent to a serial schedule.

https://play.google.com/store/apps/details? Page: 9 / 30
 www.BrainKart.
com

Consider the schedule 8 shown in Fig. It is view equivalent to the serial schedule. <T3, T4,
T6> since one read (Q) instruction reads the initial value of Q in both schedules, and T5 performs
the final write of Q in both schedules.
T3 T4 T6
read (Q)

write (Q)

write (Q)
write (Q)
Schedule 8-a view serializable schedule
Every conflict serializable schedule is also view serializable, but there are view serializable
schedules that are not conflict serializable.

In schedule 8, transactions T4 and T6 performs write (Q) operations without having

performed a read (Q) operation. Writes of this sort are called blind writes. Blind writes appear in
any view-serializable schedule that is not conflict serializable.

Testing for Serializability

Testing for serializability is done by using a directed graph, called precedence graph,
constructed from schedule. This graph consists of a pair G = (V , E), where V is a set of vertices
and E is a set of edges. The set of vertices consists of all transactions in schedule. The set of
edges consists of all edges Ti Tj for which one of three conditions holds:

1. Ti executes write (Q) before Tj executes read (Q)

2. Ti executes read (Q) before Tj executes write (Q)

3. Ti executes write (Q) before Tj executes write (Q).

The precedence graph for schedule 1 is shown in Fig. 5.11 (a), it contains a single edge
T1 T2, since all the instructions of T1 are executed before the first instruction of T2 is executed.
T1 T2 T2 T1
(a) (b)
Fig 3.2 Precedence graph for (a) schedule 1 and (b) schedule 2
The above figure shows the precedence graph for schedule 2 with single edge T2 T1 since
all the instructions of T2 are executed before the first instruction of T1 is executed.

https://play.google.com/store/apps/details? Page: 10 / 30
 www.BrainKart.
com

Example: Consider the following schedule 9.

T1 T2
read (A)
A: = A-50
read (A)
temp: = A*0.1
A: = A- temp
write (A)
write (B)
write (A)
read (B)
B: = B + 50
write (B)
B: = B + temp
write (B)

Schedule 9
The precedence graph for schedule 9 is shown below

T1 T2

Fig 3.3 Precedence graph for schedule 9

A serializability order of the transactions can be obtained through topological sorting,
which determines a linear order consistent with the partial order of the precedence
graph.

(a) Test for Conflict Serializability

To test conflict serializability, construct a precedence graph for given schedule. If graph
contains cycle, the schedule is not conflict serializable. If the graph contains no cycle, then the
schedule is conflict serializable.
Schedule 1 and schedule 2 are conflict serializable, as the precedence graph for both
schedules does not contain any cycle. However the schedule 9 is not conflict serializable, as
precedence graph for it contains cycle.
Example: Consider the schedule given in Fig. Find out whether that schedule is conflict
serializable or not?
T9 T10 T11
read (A)
A := f1(A)
write (A)
read (A)
A : = f2(A)
write (A)
read (B)
B : = f3(B)
write (B)
read (B)
B : = f4(B)
write (B)

https://play.google.com/store/apps/details? Page: 11 / 30
 www.BrainKart.
com

Concurrent schedule
Solution:

T9 T10 T11

Fig 3.4 The precedence graph for given schedule is

As the graph is acyclic, so the schedule is conflict serializable.

(b) Test for View Serializability

The precedence graph used for testing conflict serializability cannot be used for testing view
serializability. We need to extend the precedence graph to include labeled edges. This graph is
called as labeled precedence graph.

Let S be a schedule. Suppose that the transaction Tj reads the value of data item
Q written by Ti. If S is view serializable, then in any serial schedule S1 that is equivalent to S, Ti
must precede Tj. Suppose that, in schedule S, transaction Tk executed a write (Q).
Then, in schedules Tk must either precede Ti or follow Tj . It cannot appear in between Ti and Tj
because Tj would not read the value of Q written by Ti and thus S would not be view equivalent
to S1. These constraints cannot be expressed using simple precedence graph, therefore labeled
precedence graph is used.

Construction of Labeled Precedence Graph

Let S be a schedule consisting of transactions {T 1, T2, ... Tn}. Let Tb and Tf be two
dummy transactions such that Tb issues write (Q) for each Q accessed in S, and Tf issues
read (Q) for each Q accessed in S. We construct a new schedule S1 from S by inserting Tb at the
beginning of S, and appending Tf to the end of S. We construct the labeled precedence graph for
schedule S1 as follows:
1. Add an edge Ti o Tj, if transaction Tj reads the value of data item Q
written by transaction Ti.
2. Remove all edges incident on useless transactions.
A transaction Ti is useless if there exists no path in the precedence graph
from Ti to transaction Tf.
3. For each data item Q such that Tj reads the value of Q written by Ti and Tk
executes write (Q) and Tk Tb, do the following:
(a) If Ti = Tb and Tj ≠ Tf, then insert the edge Tj − o Tk in
labeled precedence graph. the
(b) If Ti ≠ Tb and Tj = Tf, then insert the edge
Tk − o Ti in
labeled precedence graph. the
(c) If Ti ≠ Tb and Tj ≠ Tf, then insert the pair of edges Tk p Ti and
Tj p Tk in the labeled precedence graph, where p is a unique
integer larger than 0 that has not been used earlier for labeled edges.
Example: Consider the following schedule. Find out whether that is view serializable or not?

https://play.google.com/store/apps/details? Page: 12 / 30
 www.BrainKart.
com

T1 T2 T3
read (Q)

write (Q)

write (Q)
write (Q)
Concurrent schedule S2
Solution: The graph constructed in step 1 and 2 is shown in Fig. 5.16 (a) and final graph
is shown in the above figure.

The graph contains the edge T1 o T2 and

T2 o T3 as a result of step 3a. It contains the edge T1 o T3 and T2 o T3 as a result of step
3b. As the graph does not contain any cycle, it is view serializable schedule.

Fig 3.5 Labelled precedence graph for schedule S2

CONCURRENCY CONTROL
The system must control the interaction among the concurrent transactions. This control
is achieve through one of concurrency control schemes. The concurrency control schemes are
based on the serializability property.
Different types of protocols/schemes used to control concurrent execution of transactions.

NEED FOR CONCURRENCY CONTROL

Locking is a protocol used to control access to data when one transaction is accessing the
database, a lock may deny access to other transactions to prevent incorrect results. Locking is one
of the most widely used mechanisms to ensure serializability.

To ensure serializability, it is required that data items should be accessed in mutual

exclusive manner; if one transaction is accessing a data item, no other transaction can modify that
data item. A transaction is allowed to access a data item only if it is currently holding a lock on
that item.

https://play.google.com/store/apps/details? Page: 13 / 30
 www.BrainKart.
com

Types of Locks

Several types of locks can be used in concurrency control. Among them two types are
important.
1. Binary locks.
2. Shared and Exclusive locks.

(i) Binary Locks

• A binary lock can have two states or values locked and unlocked (0 and 1, for
simplicity).
• A distinct lock is associated with each data base item X.
• If the value of the lock on X is 1, item X cannot be accessed by a database operation
that requests the item.
• If the value of the lock on X is 0, the item can be accessed when
requested. We refer to the value of the lock associated with item X as Lock(X).
• Two operations, lock_item and unlock_item must be included in the
transactions when binary locking is used.
• A transaction requests access to an item X by issuing a lock_item(X)
operation.
• If lock(X) = 1, the transaction is forced to wait otherwise, the transaction
sets lock(X) : = 1 (locks the item) and is allowed access
• When the transaction is through using the item, it issues an unlock_item (X) operation,
which sets lock (X) : = 0 (unlocks the item) so that X may be accessed by other
transactions.
Hence a binary lock enforces mutual exclusion on the data item.
A description of the lock_item (X) and unlock-item (X) operations is shown below:
lock_item(X):
B : if lock(X) = 0 (* item is unlocked *)
then lock(X) 1 (*lock the item *)
else begin
wait (until lock(X) = 0 and the lock manager wakes up the
transaction); go to B;
end;
unlock_item(X):
lock(X) 0 (* unlock the item *)
if any transaction are waiting then wakeup one of the waiting transactions.
Lock and unlock operation for binary locks

https://play.google.com/store/apps/details? Page: 14 / 30
 www.BrainKart.
com

(ii) Shared and Exclusive Lock

(i) Shared Mode Lock
If a transaction Ti has obtained a shared mode lock on item Q, then Ti can
read, but cannot write Q. It is denoted by S.
(ii) Exclusive Mode Lock
If a transaction Ti has obtained an exclusive lock on item Q, then Ti can read
and also write Q. It is denoted by X.
A transaction requests a shared lock on data item Q by executing the lock-S(Q)
instruction. Similarly, a transaction requests an exclusive lock through the lock-X(Q) instruction.
A transaction can unlock a data item Q by the unlock (Q) instruction.
Given a set of lock modes, we can define a compatibility function on them as follows.
Let A and B represent arbitary lock modes. Suppose that a transaction Ti requests a lock of mode
A on item Q on which transaction Tj (Ti Tj) currently hold a lock of mode B. If transaction Ti
can be granted a lock of Q immediately, in spite of the presence of the mode B lock, then we say
mode A is compatible with mode B such a function is represented by a matrix. The matrix is
shown in Fig. 3.6
S S

SX true false

ffaallssee
Fig 3.6 Lock-compatibility matrix ‘comp’
To access a data item, transaction Ti must first lock that item. If the data item is
already locked by another transaction in an incompatible mode, the concurrency
control manager will not grant the lock until all incompatible locks held by other transactions
have released. Thus, Ti is made to wait until all incompatible locks held by other transactions
have been released.

LOCKING PROTOCOLS

Each transaction in the system should follow a set of rules, called locking protocol,
indicating when a transaction may lock and unlock each of the data items. Locking protocol
restricts the number of possible schedules.
Granting of Locks
When a transaction requests a lock on the data item in a particular mode and no other
transaction has a lock on the same data item in a conflicting mode, the lock can be granted.
However, care must be taken while granting the locks.
For example, consider a transaction T2 has a shared mode lock on data item Q, and
another transaction T1 requests an exclusive-mode lock on the same data item. In this case, T1 has
to wait for T2 to release the shared - mode lock. Mean while, another transaction T3 requests the
shared mode lock on Q. The lock request is compatible with the lock granted to T2, so T3 may be
granted the shared-mode lock.
At this point, T2 may releases the lock, but still T1 has to wait for T3 to release the lock.
Thus it is possible that sequence of transactions that each requests a shared-mode lock on Q, and
each transaction releases the lock a short while after it is granted, but T1 may never gets the

https://play.google.com/store/apps/details? Page: 15 / 30
 www.BrainKart.
com

exclusive mode lock on the data item. The transaction T1 may never make progress 1 and is said
to be starved.
Starvation of transaction can be avoided by granting locks in the following manner. 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.
Two-phase Locking Protocol
This protocol requires that each transaction issue lock and unlock requests in two phases.
3. Growing phase: A transaction may obtain locks, but may not release any lock.
4. Shrinking phase: A transaction may release locks, but may not obtain any new
locks.
Initially, a transaction is in the growing phase. The transaction aquires locks as needed.
Once a transaction releases a lock, it enters in the shrinking phase, and it cannot issue more lock
requests.
For example, transactions T3 is two phase. But transactions T1 and T2 are not two phase.
Note that the unlock instructions do not need appear at the end of the transaction.
T3: lock-X (B);

read (B);
B: = B-50;
write (B);
lock-X (A);
read (A); A: = A=50;
write (A); unlock (B); unlock (A);
Fig. 3.7 Transaction T3
Advantages
The two-phase locking protocol ensures conflict serializability.
Consider any transaction, the point in the schedule where the transaction has obtained its
final lock is called the lock-point of the transaction. Now, the transactions can be ordered
according to their lock points. This ordering is the serializability ordering for the transactions.
Disadvantages
1. It does not ensure freedom from deadlock.
2. Cascading rollbacks may occur under two-phase locking.

https://play.google.com/store/apps/details? Page: 16 / 30
 www.BrainKart.
com

Types:
1. Strict two phase locking protocol
This protocol requires that locking should be two phase, and all exclusive-mode locks taken
by a transaction should be held until the transaction. This requirement prevents any transaction
from reading the data written by any uncommitted transaction under exclusive mode until the
transaction commits, preventing any other transaction from reading the data.
2. Rigorous two phase locking protocol
This protocol requires that all locks be held until the transaction commits. We can easily
verify that, with rigorous two-phase locking, transactions can be serialized in the order in which
they commit.Most database systems implement either strict or rigorous two-phase locking.
Two-phase locking protocol allows lock conversions. There is a mechanism for upgrading
a shared lock to an exclusive lock, downgrading an exclusive lock to a shared lock. We donote
the conversion from shared to exclusive modes by upgrade, and from exclusive to shared by
downgrade. Lock conversion cannot be allowed arbitrarily.
Strict two-phase locking and rigorous two-phase locking (with lock conversions) are used
extensively in commercial database systems.
A simple but widely used scheme automatically generates the appropriate lock and unlock
instructions for a transaction, on the basis of read and write requests from the transaction:
• When a transaction Ti issues a read (Q) operation, the system issues a lock-
S(Q) instruction followed by the read (Q) instruction.

• When Ti issues a write (Q) operation, the system checks to see whether Ti
already holds a shared lock on Q. If it does, then the system issues an upgrade
(Q) instruction, followed by the write (Q) instruction. Otherwise, the system issues a
lock - X(Q) instruction, followed by the write (Q) instruction.
• All locks obtained by a transaction are unlocked after that transaction commits or
aborts.

DEADLOCKS

A system is in a deadlock state if there exists a set of transactions such that every
transaction in the set is waiting for another transaction in the set.

In other words, there exists a set of waiting transactions such that T0 is waiting for a data
item that T1 holds and T1 is waiting for a data item that T2 holds and ..., and Tn-1 is waiting for a
data item that Tn holds, and Tn is waiting for a data item that T0 holds. In such a situation, none
of the transactions can make progress.

There are two principal methods for dealing with the deadlock problem.
(i) Deadlock prevention: This approach ensures that system will never enter in
deadlock state.
(ii) Deadlock detection and recovery: This approach tries to recover from
deadlock if system enters in deadlock state.

https://play.google.com/store/apps/details? Page: 17 / 30
 www.BrainKart.
com

Deadlock Prevention
There are two approaches for deadlock prevention:
(a) One approach ensures that no cyclic waits can occur by ordering the requests
for locks, or requiring all locks to be acquired together. This approach
requires that each transaction locks all data items before it begins execution. It is
required that, either all data items should be locked in one step, or none should be
locked.
Disadvantages of this approach are
1. It is hard to predict before the transaction begins, what data items need to be
locked.
2. Data-item utilization may be very low, since many of the data items may be
locked but unused for long time.
(b) The second approach for deadlock prevention is to use pre-emption and
transaction rollbacks. In pre-emption when a transaction T2 requests a lock
that transaction T1 holds, the lock granted to T1 may be pre-empted by rolling
back of T1, and granting of the lock to T2.
To control pre-emption, a unique timestamp is assigned to each transaction. The system
uses timestamp to decide whether a transaction should wait or roll back.
Two different deadlock prevention schemes using timestamp are:

(i) Wait-die
The wait-die scheme is non-pre-emption technique. In this, when transaction Ti
requests a data item held by Tj, Ti is allowed to wait only if it has a timestamp
smaller than Tj. (That is Ti is older than Tj). Otherwise, Ti is rolled back (dies).
For example, suppose that transactions T22, T23, and T24 have timestamps 5, 10 and 15
respectively. 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.
(ii) Wound-wait
The wound-wait is pre-emptive technique. In this, when transaction Ti requests data
item-held by Tj, Ti is allowed to wait, only if it has timestamp greater than Tj (that
is Ti is younger than Tj). Otherwise Tj is rolled back.
Returning to same example, if T1 requests a data item hold by T2, then the data item
will be preempted by T2, and T2 will be rolled back. If T3 requests a data item held
by T2 then T3 will wait.
Differences between two schemes
• 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.

https://play.google.com/store/apps/details? Page: 18 / 30
 www.BrainKart.
com

• In the wait-die scheme, if a transaction Ti dies and is rolled back because it requested
a data item held by transaction Tj , then Ti may re-issue 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. 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.
Timeout-Based Schemes
This approach for deadlock handling is based on lock timeouts. In this approach, a
transaction that has requested a lock waits for at most a specified amount of time. If the lock has
not been granted within that time, the transaction is said to be time out, and it rolls back itself and
restarts. Thus, if there was a deadlock one or more transactions involved in the deadlock will
time out and roll back, allowing the others to proceed.
Advantages
1. This scheme is easy to implement.
2. It works well if transactions are short, and if long, waits are likely to be due to
deadlocks.
Disadvantages
1. It is hard to decide how long a transaction should wait. Too long waits results in
unnecessary delays once a deadlock has occurred, and too short a wait results in
transaction rollbacks even when there is no deadlock.
2. Starvation is also possible with this scheme.

Deadlock Detection and Recovery

This approach uses an algorithm that examines the state of the system periodically to
determine whether a deadlock has occurred. If one has occurred, then the system attempts to
recover from the deadlock.
Deadlock Detection
Deadlocks can be described in terms of directed graphs called a wait-for graph. This
graph consists of a pair G = (V, E), where
V- set of vertices consists of all transactions in the system.
E-set of edges.
If Ti Tj is in E, then there is a directed edge from transaction Ti to Tj. When transaction Ti
requests a data item currently held by transaction Tj, then the edge Ti Tj is inserted in the wait
for graph. A deadlock exists in the system if and only if the wait for graph contains a cycle. Each
transaction involved in the cycle is said to be dead locked.
Example: Consider the wait for graph shown in Fig. 3.8 (a)

https://play.google.com/store/apps/details? Page: 19 / 30
 www.BrainKart.
com

T26 T28

T25

T27

Fig. Wait for graph with no cycle

The graph depicts the following situation:
❖ Transaction T25 is waiting for transaction T26 and T27
❖ Transaction T27 is waiting for transaction T26
❖ Transaction T26 is waiting for transaction T28.
This graph has no cycle, therefore the system is not in a deadlock state.
Consider the graph shown in Fig. 3.8(b)

T26 T28

T25

T27

Fig. Wait for graph with a cycle

The above graph contains the cycle

T26 T28 T27 T26
implying that transactions T26, T27, T28 are all deadlocked.
If deadlocks occur frequently, then the detection algorithm should be invoked more
frequently than usual. Data items allocated to deadlocked transactions will be unavailable to
other transactions until the deadlock can be broken.
Recovery from Deadlock
When a deadlock detection algorithm determines that a deadlock exists, the system must
recover from the deadlock. The most common solution is to rollback one or more transactions to
break the deadlock.
Three actions need to be taken:
1. Selection of a victim
Given a set of deadlocked transactions, we must determine which transaction should be
rolled back to break the deadlock. Roll back those transactions that will incur minimum
cost. Unfortunately the term minimum cost is not a precise one. Many factors may
determine the cost of a rollback
(i) How long the transaction has computed, and how much longer the
transaction will compute before it completes its designated task ?
(ii) How many data items the transaction has used ?
(iii) How many more data items the transaction needs for it to complete ?

https://play.google.com/store/apps/details? Page: 20 / 30
 www.BrainKart.
com

(iv) How many transactions will be involved in the rollback?

2. Rollback
Once we have decided to roll back particular transaction, we must determine how for this
transaction should be rolled back. The solutions are:
(i) Total rollback: Abort the transaction and then restarts it.
(ii) Partial rollback: It is more effective to roll back the transaction only as far as necessary to
break the deadlock. It requires the system to maintain additional information about the state
of all the running transactions. Specifically, the sequence of lock requests/grants and updates
performed by the transaction needs to be recorded.
3. Starvation
It is possible that, same transaction will be rolled back number of times to break the
deadlock. As a result, this transaction never completes its designated task, thus there is
starvation. To avoid this, we must ensure that transactions can be picked as a victim only a
small number of times.

TRANACTION RECOVERY
❖ Protocols that obey this are referred to as non-blocking protocols. In the following two
sections, we consider two common commit protocols suitable for distributed DBMSs:
two-phase commit (2PC) and three-phase commit (3PC), a non-blocking protocol.
❖ Assume that every global transaction has one site that acts as coordinator (or
transaction manager) for that transaction, which is generally the site at which the
transaction was initiated. Sites at which the global transaction has agents are called
participants (or resource managers).
❖ Assume that the coordinator knows the identity of all participants and that each
participant knows the identity of the coordinator but not necessarily of the other participants.

Two-Phase Commit (2PC)

❖ 2PC operates in two phases: a voting phase and a decision phase.

❖ The basic idea is that the coordinator asks all participants whether they are prepared to
commit the transaction. If one participant votes to abort, or fails to respond within a
timeout period, then the coordinator instructs all participants to abort the transaction.
❖ If all vote to commit, then the coordinator instructs all participants to commit the
transaction. The global decision must be adopted by all participants.
❖ If a participant votes to abort, then it is free to abort the transaction immediately; in fact,
any site is free to abort a transaction at any time up until it votes to commit. This type of
abort is known as a unilateral abort.
❖ If a participant votes to commit, then it must wait for the coordinator to broadcast either
the global commit or global abort message.
❖ This protocol assumes that each site has its own local log, and can therefore rollback or
commit the transaction reliably. Two-phase commit involves processes waiting for
messages from other sites. To avoid processes being blocked unnecessarily, a system of
timeouts is used. The procedure for the coordinator at commit is as follows:

https://play.google.com/store/apps/details? Page: 21 / 30
 www.BrainKart.
com

Phase 1

(1) Write a begin_commit record to the log file and force-write it to stable storage.
✓ Send a PREPARE message to all participants.
✓ Wait for participants to respond within a timeout period.
Phase 2

(1) If a participant returns an ABORT vote,

✓ Write an abort record to the log file and forcewrite it to stable storage.
✓ Send a GLOBAL_ABORT message to all participants.
✓ Wait for participants to acknowledge within a timeout period.
(2) If a participant returns a READY_COMMIT vote,
✓ Write a commit record to the log file and force-write it to stable storage.
✓ Send a GLOBAL_COMMIT message to all participants.
✓ Wait for participants to acknowledge within a timeout period.
(3) Once all acknowledgements have been received,
✓ Write an end_transaction message to the log file.

2PC Protocol for voting Commit:

Fig 2 PC Protocol for voting Commit

https://play.google.com/store/apps/details? Page: 22 / 30
 www.BrainKart.
com

2PC Protocol for voting Abort:

Fig. 2PC Protocol for voting Abort

Termination protocols for 2PC

A termination protocol is invoked whenever a coordinator or participant fails to receive

an expected message and times out. The action to be taken depends on whether the coordinator or
participant has timed out and on when the timeout occurred.

(i) Coordinator
The coordinator can be in one of four states during the commit process:
❖ INITIAL
❖ WAITING
❖ DECIDED
❖ COMPLETED
as shown in the state transition diagram in Figure, but can time out only in the middle two states.
The actions to be taken are as follows:

Timeout in the WAITING state -The coordinator is waiting for all participants to
acknowledge whether they wish to commit or abort the transaction. In this case, the coordinator
cannot commit the transaction because it has not received all votes. However, it can decide to
globally abort the transaction.

Timeout in the DECIDED state -The coordinator is waiting for all participants to
acknowledge whether they have successfully aborted or committed the transaction. In this case,

https://play.google.com/store/apps/details? Page: 23 / 30
 www.BrainKart.
com

The coordinator simply sends the global decision again to sites that have not acknowledged.

Fig.3.11 Termination protocols for 2PC

(ii) Participant
A participant can be in one of four states during the commit process:
❖ INITIAL
❖ PREPARED
❖ ABORTED
❖ COMMITTED
as shown in the state transition diagram in Figure. However, a participant may time out only in
the first two states as follows:
Timeout in the INITIAL state-The participant is waiting for a PREPARE message from
the coordinator, which implies that the coordinator must have failed while in the INITIAL state.
In this case, the participant can unilaterally abort the transaction. If it subsequently receives a
PREPARE message, it can either ignore it, in which case the coordinator times out and aborts the
global transaction, or it can send an ABORT message to the coordinator.

Timeout in the PREPARED state-The participant is waiting for an instruction to globally

commit or abort the transaction. The participant must have voted to commit the transaction, so it
cannot change its vote and abort the transaction. Equally well, it cannot go ahead and commit the
transaction, as the global decision may be to abort.

3.9.1.2 Recovery protocols for 2PC

(i) Coordinator failure

Consider three different stages for failure of the coordinator:
❖ Failure in INITIAL state-The coordinator has not yet started the commit
procedure. Recovery in this case starts the commit procedure.

https://play.google.com/store/apps/details? Page: 24 / 30
 www.BrainKart.
com

❖ Failure in WAITING state-The coordinator has sent the PREPARE message

and although it has not received all responses, it has not received an abort
response. In this case, recovery restarts the commit procedure.
❖ Failure in DECIDED state-The coordinator has instructed the participants to
globally abort or commit the transaction. On restart, if the coordinator has
received all acknowledgements, it can complete successfully.

(ii) Participant failure

Consider three different stages for failure of a participant:

❖ Failure in INITIAL state-The participant has not yet voted on the transaction.
Therefore, on recovery it can unilaterally abort the transaction, as it would have
been impossible for the coordinator to have reached a global commit decision
without this participant’s vote.
❖ Failure in PREPARED state-The participant has sent its vote to the
coordinator. In this case, recovery is via the termination protocol discussed
above.
❖ Failure in ABORTED/COMMITTED states-The participant has completed
the transaction. Therefore, on restart, no further action is necessary.

SAVE POINTS

A SAVEPOINT is a point in a transaction when you can roll the transaction back to a
certain point without rolling back the entire transaction.
The syntax for a SAVEPOINT command is as shown below.

SAVEPOINT SAVEPOINT_NAME;

This command serves only in the creation of a SAVEPOINT among all the transactional
statements. The ROLLBACK command is used to undo a group of transactions.
The syntax for rolling back to a SAVEPOINT is as shown below.

ROLLBACK TO SAVEPOINT_NAME;

Following is an example where you plan to delete the three different records from the
CUSTOMERS table. You want to create a SAVEPOINT before each delete, so that you can
ROLLBACK to any SAVEPOINT at any time to return the appropriate data to its original state.
Example
Consider the CUSTOMERS table having the following records.
ID NAME AGE ADDRESS SALARY
1 Suresh 23 Chennai 5400
2 Mano 22 Cochin 6500
3 Subhiksha 23 Newyork 4500

https://play.google.com/store/apps/details? Page: 25 / 30
 www.BrainKart.
com

4 Malar 24 Bangalore 4300

5 Sarath 22 Trichy 7500
6 Krishna 32 Coimbatore 6600
7 Ranchana 21 Hyderabad 5500

The following code block contains the series of

operations. SQL> SAVEPOINT SP1;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=1;
1 row deleted.
SQL> SAVEPOINT SP2;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=2;
1 row deleted.
SQL> SAVEPOINT SP3;
Savepoint created.
SQL> DELETE FROM CUSTOMERS WHERE ID=3;
1 row deleted.
Now that the three deletions have taken place, let us assume that you have changed your mind
and decided to ROLLBACK to the SAVEPOINT that you identified as SP2. Because SP2 was
created after the first deletion, the last two deletions are undone −
SQL> ROLLBACK TO SP2;
Rollback complete.
Notice that only the first deletion took place since you rolled back to SP2.
ID NAME AGE ADDRESS SALARY
2 Mano 22 Cochin 6500
3 Subhiksha 23 Newyork 4500
4 Malar 24 Bangalore 4300
5 Sarath 22 Trichy 7500
6 Krishna 32 Coimbatore 6600
7 Ranchana 21 Hyderabad 5500
6 rows selected

https://play.google.com/store/apps/details? Page: 26 / 30
 www.BrainKart.
com

RELEASE SAVEPOINT Command

RELEASE SAVEPOINT command is used to remove a SAVEPOINT that you have
created.
The syntax for a RELEASE SAVEPOINT command is as follows.
RELEASE SAVEPOINT SAVEPOINT_NAME;
Once a SAVEPOINT has been released, you can no longer use the ROLLBACK command to
undo transactions performed since the last SAVEPOINT.
ISOLATION LEVELS

Isolation levels determine the type of phenomena that can occur during the execution of
concurrent transactions
Three phenomena define SQL Isolation levels for a transaction:
1. Dirty Reads returns different results within a single transaction when an SQL operation
an uncommitted or modified record created by another transaction. Dirty Reads increases
concurrency, but reduces consistency.
2. Non-Repeatable Reads returns different results within a single transaction when an SQL
operation reads the same row in a table twice. Non-Repeatable Reads can occur when another
transaction modifies and commits a change to the row between transaction reads. Non-repeatable
reads increases consistency, but reduces concurrency.
3. Phantoms returns different results within a single transaction when an SQL operation
retrieves a range of data values twice. Phantoms can occur if another transaction inserted a new
record and committed the insertion between executions of the range retrieval.
Each Isolation level differs in the phenomena it allows:

Transaction isolation Dirty Nonrepeatable

level reads reads Phantoms

Read uncommitted X X X

Read committed -- X X

Repeatable read -- -- X

Serializable -- -- --

❖ Read Uncommitted – Read Uncommitted is the lowest isolation level. In this level, one
transaction may read not yet commited changes made by other transaction, thereby allowing
dirty reads. In this level, transactions are not isolated from each other.

❖ Read Committed – This isolation level guarantees that any data read is committed at the
moment it is read. Thus it does not allows dirty read. The transaction hold a read or write
lock on the current row, and thus prevent other rows from reading, updating or deleting it.

https://play.google.com/store/apps/details? Page: 27 / 30
 www.BrainKart.
com

❖ Repeatable Read – This is the most restrictive isolation level. The transaction holds read
locks on all rows it references and write locks on all rows it inserts, updates, or deletes. Since
other transaction cannot read, update or delete these rows, consequently it avoids non
repeatable read.

❖ Serializable – This is the Highest isolation level. A serializable execution is guaranteed to be

serializable. Serializable execution is defined to be an execution of operations in which
concurrently executing transactions appears to be serially executing.

SQL FACILITIES FOR CONCURRENCY CONTROL

Crash Recovery
DBMS is a highly complex system with hundreds of transactions being executed every
second. The durability and robustness of a DBMS depends on its complex architecture and its
underlying hardware and system software. If it fails or crashes amid transactions, it is expected
that the system would follow some sort of algorithm or techniques to recover lost data.

Failure Classification
To see where the problem has occurred, we generalize a failure into various categories,
as follows –

Transaction failure
A transaction has to abort when it fails to execute or when it reaches a point from where
it can’t go any further. This is called transaction failure where only a few transactions or
processes are hurt.
Reasons for a transaction failure could be −
• Logical errors − Where a transaction cannot complete because it has some code error or
any internal error condition.
• System errors − Where the database system itself terminates an active transaction
because the DBMS is not able to execute it, or it has to stop because of some system
condition. For example, in case of deadlock or resource unavailability, the system aborts
an active transaction.
System Crash
There are problems − external to the system − that may cause the system to stop abruptly
and cause the system to crash. For example, interruptions in power supply may cause the failure
of underlying hardware or software failure.
Examples may include operating system errors.
Disk Failure
In early days of technology evolution, it was a common problem where hard-disk drives
or storage drives used to fail frequently. Disk failures include formation of bad sectors,
unreachability to the disk, disk head crash or any other failure, which destroys all or a part of
disk storage.

https://play.google.com/store/apps/details? Page: 28 / 30
 www.BrainKart.
com

Storage Structure
We have already described the storage system. In brief, the storage structure can be divided into
two categories −
• Volatile storage − As the name suggests, a volatile storage cannot survive system
crashes. Volatile storage devices are placed very close to the CPU; normally they are
embedded onto the chipset itself. For example, main memory and cache memory are
examples of volatile storage. They are fast but can store only a small amount of
information.
• Non-volatile storage − These memories are made to survive system crashes. They are
huge in data storage capacity, but slower in accessibility. Examples may include hard-
disks, magnetic tapes, flash memory, and non-volatile (battery backed up) RAM.
Recovery and Atomicity
When a system crashes, it may have several transactions being executed and various files
opened for them to modify the data items. Transactions are made of various operations, which
are atomic in nature. But according to ACID properties of DBMS, atomicity of transactions as a
whole must be maintained, that is, either all the operations are executed or none.
When a DBMS recovers from a crash, it should maintain the following −
• It should check the states of all the transactions, which were being executed.
• A transaction may be in the middle of some operation; the DBMS must ensure the
atomicity of the transaction in this case.
• It should check whether the transaction can be completed now or it needs to be rolled
back.
• No transactions would be allowed to leave the DBMS in an inconsistent state.
There are two types of techniques, which can help a DBMS in recovering as well as maintaining
the atomicity of a transaction −
• Maintaining the logs of each transaction, and writing them onto some stable storage
before actually modifying the database.
• Maintaining shadow paging, where the changes are done on a volatile memory, and later,
the actual database is updated.
Log-based Recovery
Log is a sequence of records, which maintains the records of actions performed by a
transaction. It is important that the logs are written prior to the actual modification and stored on
a stable storage media, which is failsafe.

Log-based recovery works as follows −

✓ The log file is kept on a stable storage media.
✓ When a transaction enters the system and starts execution, it writes a log about it.
✓ <Tn, Start>
✓ When the transaction modifies an item X, it write logs as follows −
✓ <Tn, X, V1, V2>
✓ It reads Tn has changed the value of X, from V1 to V2.

https://play.google.com/store/apps/details? Page: 29 / 30
 www.BrainKart.
com

✓ When the transaction finishes, it logs −

✓ <Tn, commit>

The database can be modified using two approaches −

• Deferred database modification − All logs are written on to the stable storage and the
database is updated when a transaction commits.
• Immediate database modification − Each log follows an actual database modification.
That is, the database is modified immediately after every operation.
Recovery with Concurrent Transactions
When more than one transaction are being executed in parallel, the logs are interleaved.
At the time of recovery, it would become hard for the recovery system to backtrack all logs, and
then start recovering. To ease this situation, most modern DBMS use the concept of
'checkpoints'.
Checkpoint
Keeping and maintaining logs in real time and in real environment may fill out all the
memory space available in the system. As time passes, the log file may grow too big to be
handled at all. Checkpoint is a mechanism where all the previous logs are removed from the
system and stored permanently in a storage disk. Checkpoint declares a point before which the
DBMS was in consistent state, and all the transactions were committed.
Recovery
When a system with concurrent transactions crashes and recovers, it behaves in the
following manner −

Fig Checkpoint versus Failure

❖ The recovery system reads the logs backwards from the end to the last checkpoint.
❖ It maintains two lists, an undo-list and a redo-list.
❖ If the recovery system sees a log with <T n, Start> and <Tn, Commit> or just <Tn,
Commit>, it puts the transaction in the redo-list.
❖ If the recovery system sees a log with <T n, Start> but no commit or abort log found, it
puts the transaction in undo-list.
All the transactions in the undo-list are then undone and their logs are removed. All the
transactions in the redo-list and their previous logs are removed and then redone before saving
their logs.

https://play.google.com/store/apps/details? Page: 30 / 30
 Click on Subject/Paper under Semester to
enter. Environmental
Professional English Sciences
Professional and Sustainability -
English - I - - II - HS3252 Discrete GE3451
HS3152
Mathematics
Statistics and Theory of Computation
- MA3354
Numerical - CS3452
Matrices and
Methods - MA3251
Calculus Digital Principles
and Computer Artificial
- MA3151

Semester
Engineering Intelligence and
Semester

Organization
Semester

Graphics Machine Learning

Semester

- CS3351
Engineering - CS3491
Physics - PH3151 - GE3251
Foundation of Data
Physics for Science - CS3352 Database Management

4th
System - CS3492
2nd
1st

Engineering Information
3rd

Chemistry Science
Data Structure -
- CY3151 - PH3256 CS3301 Algorithms - CS3401
Basic Electrical and
Electronics Object Oriented Introduction to
Problem Solving Engineering Operating
Programming -
and Python - BE3251 Systems - CS3451
CS3391
Programming -
GE3151 Programming in C
- CS3251

Computer
Networks - Object Oriented
CS3591 Software
Engineering
- CCS356 Human Values and
Compiler Design - Ethics - GE3791
CS3501 Embedded
Semester

Semester

Systems and IoT - Open Elective 2

Cryptography CS3691
Semester

Project Work /
Semester

and Cyber
Security - Open Elective 3 Intership
CB3491 Open
Open Elective 4
5th

7th

Distributed Elective-1
8th

Computing
6th

Management
- CS3551 Elective-3
Elective
Elective 1 Elective-4

Elective 2 Elective-5

Elective-6
 All Computer Engg [ B.E., M.E., ] (Click on Subjects to
Subjects - enter)

Programming in C Computer Operating Systems

Networks
Programming and Data Programming and Problem Solving and
Structures I Data Python
Structure II Programming
Database Management Computer Analog and Digital
Systems Architecture Communication
Design and Analysis of Microprocessors and Object Oriented
Algorithms Microcontrollers Analysis
and Design
Software Engineering Discrete Internet Programming
Mathematics
Theory of Computation Computer Graphics Distributed Systems
Mobile Computing Compiler Design Digital Signal
Processing
Artificial Intelligence Software Testing Grid and Cloud
Computing
Data Ware Housing and Cryptography and Resource
Data Mining Network Security Management
Techniques
Service Oriented Embedded and Real Multi - Core
Architecture Time Systems Architectures and
Programming
Probability and Queueing Physics for Transforms and
Theory Information Partial Differential
Science Equations
Technical English Engineering Engineering Chemistry
Physics
 Engineering Graphics Total Quality Professional Ethics in
Management Engineering
Basic Electrical and Problem Solving Environmental Science
Electronics and and Python and Engineering
Measurement Engineering Programming