4/3/2025

1. Transaction: 2. Schedule:
• Definition • Types of Schedule
• ACID Properties • Serializability
• Transaction States

MODULE
DISCUSSION

3. Concurrency Control Protocol: 4. Recovery System:

• Lock Based • Log based Recovery
• Timestamp Based • Checkpoint
• Shadow paging

Transaction
It is a collection of operations.

It is a program unit whose execution may change the content of database.

T1
Update Bank DB Select
T3

T2
Insert

A DB before transaction DB after transaction

It should be
consistent state

1
 4/3/2025

ACID Properties

In order to preserve integrity (correctness), accuracy and completeness

transaction must satisfy ACID property.

1. 2.
ATOMICITY CONSISTENCY

3. 4.

ISOLATION DURABILITY

1.Atomicity
Transaction must be atomic (all transaction is completed or none)

All or nothing rule

Example:- Transfer 100/- from account A to account B

Read(A)
A:A-100
Write(A)
Read(B)
B:B+100
Write(B)
Commit

2
 4/3/2025

2. Consistency
Logically correct which means that the integrity constraint must be maintained so that DB
is in maintained. Example:-
SUM(A,B) SUM(A,B)
Before After
500+200 400+300
3. Isolation 700 700
Transaction will be isolation means before completing a transaction, it should not be visible
to another transaction.
A: 500 B: 200
OR T1 T2
Read(A) Read(B)
Action performed by a transaction will be isolated or A-100 B:B+100
hidden from outside transaction unless until its Write(A)
In T1,
terminal.
A+B= Read(B) Read(A) In T2,
400+300 A+B=
Note:- “The resource data used during B+100 Read(B)
= 700 400+20
execution of first transaction can’t used for Write(B)
0=600
Second transaction unless the first one is completed. ”

4. Durability
All updates done by transactions must become permanent until we changes the values in
DB will not be removed.
Only valid Written data
data is saved will not be
lost

A 0
C 0I 0
D

Transactions Transactions
are all or don’t effect
nothing each other

3
 4/3/2025

Transaction state

PARTIAL permanent
COMMITED
COMMITED state
STATE
STATE

ACTIVE TERMINATED

Failure
SATAE STATE

FAILED Rollback ABORTED

STATE STATE

Figure:- State of Transaction

Schedule
“When transaction run concurrently then the higher order of execution is
known as schedule.”
OR
“Schedule is nothing but a representation, it represents the order in which
the operations of the transactions are executed.”
Is it
possible?
T1 T2 T1 T2 T1 T2 T1 T2
T1 O1 O2 O1 A1 O1 O2
O2 A2 A1 O1
T2 A1 A2 A1 O1 O2 A2
A2 O2 A2 A1
Note:-
“All the instructions of each individual transaction will appear in the schedule contact
switching can be done but we cannot change the order of execution.”

4
 4/3/2025

Concurrency Control
Concurrency:-executing multiple transactions at a time in a shared DB.

concurrency control deals with interleaved execution of more than one transaction.

Why we required concurrency in DB ? So many

people are
Accessing Tatkal accessing the
Railway DB tatkal tickets
Tickets
at a same
time

Advantage of concurrency :
1. Reduce or decreased waiting time, response or turn around time.
2. Increase throughput or resource utilization.
3. Increase efficiency.

Simultaneously execution of transaction over a

shared DB can create several data integrity and If there is so
many
consistency problem. advantages,
then why we
Interleaving of operation between transaction may are controlling
concurrency ???
also lead to many problems.

The main Problems are :-

1. Lost update
2. Dirty read
3. Unrepeatable
4. Phantom Read

5
 4/3/2025

1. LOST UPDATE PROBLEM (w-w conflict)

In the lost update problem, an update done to a data item by a
transaction is lost as it is overwritten by the update done by another
transaction.
T1 T2
Blind
R(A) write
W(A)
W(A)
COMMIT;
COMMIT;

2. DIRTY READ PROBLEM (W-R Conflict)

If a transaction reads an uncommitted temporary value
written by some other transaction that it is called dirty read
problem.
T1 T2
R(A)
W(A)
R(A)
Commit
R(B)
W(B)
Abort

6
 4/3/2025

3. UNREPEATABLE PROBLEM (R-W Conflict)

The unrepeatable problem occurs when two or more read operations of
the same transaction read different values of the same variable.

T1 T2

R(X)

R(X)

W(X)

R(X)

4. PHANTOM READ PROBLEM

The phantom read problem occurs when a transaction reads a
variable once but when it tries to read that same variable again, an
error occurs saying that the variable does not exist.
T1 T2
R(A)
R(A)
DELETE(A)
R(A)

7
 4/3/2025

Types of Schedule
Conflict

Serializable

Serial View

Schedule

Non-serial Cascading

Recoverable
Cascade less
Non- scheduler

serializable Non
Strict
recoverable

SERIAL SCHEDULE
In serial schedule, a transaction does not start execution until the currently
running transaction finished execution.
This type of execution of transaction is also known as non-interleaved execution.
T1 T2
R(A)
A=A+20
W(A)
Commit
R(A)
A=A+50
W(A)

Commit

8
 4/3/2025

Advantage AND Disadvantage :

ADVANTAGE:
• Every serial schedule always pursue (follow) the correctness.

DISADVANTAGE:
• Less degree of concurrency
• Throughput is very less
• Resource utilization is not good

NON-SERIAL SCHEDULE
If interleaving of operations is allowed, then there will be non-serial
schedule.
It contains many possible orders in which the system can execute the
individual operations of the transactions.

T1 T2
READ(A)
A=A-10
READ(A)
A=A+50
WRITE(A)
READ(B)
WRITE(A)
B=B+10
WRITE(B)

9
 4/3/2025

Conflict serializable
• A schedule is said to be conflict serializable if it can transform into a
serial schedule after swapping of non-conflicting operations.

• It is a type of serializability that can be used to check whether the

non-serial schedule is conflict serializable or not.

Conflicting operations: The two operations are called conflicting

operations, if all the following three conditions are satisfied:
1. Both the operation belongs to separate transactions.
2. Both works on the same data item. Note: Conflict pairs
for the same data
3. At least one of them contains one write operation item are: RW, WW
and WR

NOTE:-Check conflict pairs in other transactions and

draw edges.

T1 T2 T3 Precedence Graphs (Directed Graph):-

R(X)
R(Y)
R(X) T2
T1
R(Y)
R(Z)
W(Y)
W(Z) T3
R(Z)
W(X)
W(Z)
Note: Conflict pairs
for the same data
item are: RW, WW
and WR

10
 4/3/2025

NOTE:-Check conflict pairs in other transactions and

draw edges.

Precedence Graphs (Directed Graph):-

T1 T2 T3
R(X) T1 T2
W(A)
W(A)
W(A)
T3

Note: Conflict pairs

for the same data
item are: RW, WW
and WR

NOTE:-Check conflict pairs in other transactions and

draw edges.

A= 100 Precedence Graphs (Directed Graph):-

BEFORE

T1 T2 T3
A=100 R(A) T1 T2
A-40 W(A)
A-40 W(A)
A-20 W(A)

AFTER A= 0 T3

T1 T2 T3
A=100 R(A)
A-40 W(A) Note: Conflict pairs
NOTE:- BEFORE and AFTER for the same data
A-40 W(A)
are view equivalent item are: RW, WW
A-20 W(A) and WR
A= 0

11
 4/3/2025

View serializable
• A schedule will view serializable if it is view equivalent to a serial schedule.

• If a schedule is conflict serializable, then it will be view serializable.

• The view serializable which does not conflict serializable contains blind writes.

NOTE
Conflict Serializable
YES NO

View Serializable May be or May not be

view serializable

Then new concept

(Blind write exists)
NO YES

NOT VIEW TEST FOR VIEW

SERIALIZABLE SERIALIZABLE

12
 4/3/2025

Condition to be satisfied for view equivalence:

Initial Read
Final Read
Write read dependency
(Draw the dependency graph) If cycle exists
then not view serializable

S1: T1 T2 S2: T1 T2
R(A) R(A)
A=A+10 A=A+10
W(A) W(A)
R(A) R(B)
A=A+10 B=B+20
W(A) W(B)
R(B) R(B)
B=B+20 B=B+20
W(B) W(B)
R(B) R(B)
B=B*10 B=B*10
W(B) W(B)

13
 4/3/2025

S: T1 T2 T3

R(A)

W(A)

W(A)

W(A)

Non-Serializable
A non-serial schedule which is not serializable is called as a non-serializable
schedule.

A non-serializable schedule is not guaranteed to produce the same effect as

produced by some serial schedule on any consistent database.

Characteristics 0f Non-serializable schedules:-

• may or may not be consistent
• may or may not be recoverable

14
 4/3/2025

Recoverable schedule
“Schedules in which transactions commit only after all transactions whose
changes they read commit are called recoverable schedules.”

In other words, if some transaction Tj is reading value updated or written by

some other transaction Ti, then the commit of Tj must occur after the commit
of Ti.

Irrecoverable Schedule
If in a schedule,

“A transaction performs a dirty read operation from an

uncommitted transaction And commits before the transaction from which
it has read the value.” then such a schedule is known as an Irrecoverable
Schedule

15
 4/3/2025

Checking whether a schedule is Recoverable or

Irrecoverable
METHOD 1: Check for conflict serializable
Yes No

Recoverable Not Recoverable

METHOD 2: Check if there exists any dirty read operation

Not exist exist

recoverable may or may not recoverable

If there exists a dirty read operation, then follow the following

cases-
Case-01:
If the commit operation of the transaction performing the dirty
read occurs before the commit or abort operation of the
transaction which updated the value, then the schedule is
irrecoverable.
Case-02:
If the commit operation of the transaction performing the dirty
read is delayed till the commit or abort operation of the
transaction which updated the value, then the schedule is
recoverable
NOTE: “No dirty read means recoverable.”

16
 4/3/2025

Recoverable Schedule

Cascading Schedule
If in a schedule, failure of one transaction causes several other dependent
transactions to rollback or abort, then such a schedule is called as
a Cascading Schedule or Cascading Rollback or Cascading Abort.

It simply leads to the wastage of CPU time.

17
 4/3/2025

Cascadeless Schedule
If in a schedule, a transaction is
not allowed to read a data item until the
last transaction that has written it is
committed or aborted, then such a
schedule is called as a Cascadeless
Schedule.

Strict Schedule
If in a schedule, a transaction is
neither allowed to read nor write a
data item until the last transaction that
has written it is committed or aborted,
then such a schedule is called as a Strict
Schedule.

18
 4/3/2025

Concurrency control protocol

The concurrency control protocols ensure the atomicity, consistency,
isolation , durability , and serializability of the concurrent execution of the
database transactions.
Concurrency Control
Protocol

Lock Based Time stamp Based

2PL Graph Based

19
 4/3/2025

Timestamp Ordering Protocol

The Timestamp Ordering Protocol is used to order the transactions based on their
Timestamps. The order of transaction is nothing but the ascending order of the
transaction creation.
The priority of the older transaction is higher that's why it executes first. To
determine the timestamp of the transaction, this protocol uses system time or
logical counter.

Basic Timestamp ordering protocol works as follows:

1. Transaction ti issues a read(x) operation:
a. if W_TS(X)>TS(Ti), THEN ROLLBACK Ti.
otherwise execute R(x)OPERATION
set R_TS(A)=MAX{R_TS(x),TS(Ti)}

2. Transaction Ti issues write(A)operation:

a. if R_TS(X)>TS(Ti) then rollback Ti
b. if W_TS(X)>TS(Ti) then rollback Ti
otherwise execute write(x) operation
set W_TS(X)=TS(Ti)

Lock-Based Protocol
In this type of protocol, any transaction cannot read or write data until it
acquires an appropriate lock on it. There are two types of lock:
1. Shared lock (lock-S):
It is also known as a Read-only lock. In a shared lock, the data item can
only read by the transaction. It can be shared between the transactions because
when the transaction holds a lock, then it can't update the data on the data
item.
2. Exclusive lock (lock-X):
In the exclusive lock, the data item can be both reads as well as written
by the transaction. This lock is exclusive, and in this lock, multiple transactions
do not modify the same data simultaneously. S_LOCK(A) X_LOCK(A)

S_LOCK(A) T F

X_LOCK(A) F F

20
 4/3/2025

Problems on Normal Locking

T1 T2
1 lock-X(B)
May not maintain
Starvation
Recoverability 2 read(B)
May not maintain Deadlock(infinite
3 B:=B-50
Serializability waiting)
4 write(B)

5 lock-S(A)

6 read(A)

7 lock-S(B)

8 lock-X(A)

9 …… ……

2Phase locking protocol

In 2PL, every transaction will lock and unlock
the data item in two different phases.

1. Growing Phase - All the locks are issued in

this phase. No locks are released, after all
changes to data-items are committed and
then the second phase (shrinking phase)
starts.

2. Shrinking phase − No locks are issued in

this phase, all the changes to data-items
are noted (stored) and then locks are
released

Disadvantages of 2PL:- Irrecoverable,

deadlock, Starvation, Cascading rollback

21
 4/3/2025

Strict 2pl
This requires that in addition to the lock being 2-Phase all Exclusive(X)
locks held by the transaction be released until after the Transaction
Commits.

Advantage:
• Recoverable
• Cascadeless

Hence, it gives us freedom from Cascading Abort which was still there in
Basic 2-PL and moreover guarantee Strict Schedules but still, Deadlocks
are possible!(disadvantage)

Rigorous 2-PL
This requires that in addition to the lock being 2-Phase all Exclusive(X)
and Shared(S) locks held by the transaction be released until after the
Transaction Commits.

Advantage:
• strict Recoverable
• Cascadeless

Note: the difference between Strict 2-PL and Rigorous 2-PL is

that Rigorous is more restrictive.

22
 4/3/2025

Conservative 2-PL
This protocol requires the transaction to lock all the items it access
before the Transaction begins execution by predeclaring its read-set
and write-set.

Conservative 2-PL is Deadlock free and but it does not ensure a

Strict schedule.

Graph based protocol

• if we wish to develop protocols that are not two phase, we need

additional information on how each transaction will access the database.
for the additional information :we have prior knowledge about the order in
which the database items will be accessed.
• A prerequisite of this protocol is that we know the order to access a
Database Item. For this we implement a Partial Ordering on a set of
the Database Items (D) {d1, d2, d3, ….., dn} . The protocol following the
implementation of Partial Ordering is stated as-
• If di –> dj then any transaction accessing both di and dj must access
di before accessing dj.
• Implies that the set D may now be viewed as a directed acyclic graph
(DAG), called a database graph.

23
 4/3/2025

Tree Based Protocol

• Partial Order on Database items determines a tree like structure.

• Only Exclusive Locks are allowed.

• The first lock by Ti may be on any data item. Subsequently, a data Q

can be locked by Ti only if the parent of Q is currently locked by Ti.

• Data items can be unlocked at any time.

Advantage:
• Ensures Conflict Serializable Schedule.
• Ensures Deadlock Free Schedule
• Unlocking can be done anytime

Disadvantage:
• Unnecessary locking overheads may happen sometimes.
• Cascading Rollbacks is still a problem.

24
 4/3/2025

Deadlock

Deadlock

 A deadlock is a condition where two or more transactions are waiting

indefinitely for one another to give up locks.
 Deadlock is said to be one of the most feared complications in DBMS
as no task ever gets finished and is in waiting state forever.

For example : In the student table,

transaction T1 holds a lock on some
rows and needs to update some rows
in the grade table. Simultaneously,
transaction T2 holds locks on some
rows in the grade table and needs to
update the rows in the Student table
held by Transaction T1.

25
 4/3/2025

Deadlock Avoidance

• When a database is stuck in a deadlock state, then it is better to

avoid the database rather than aborting or restating the database.
This is a waste of time and resource.
• Deadlock avoidance mechanism is used to detect any deadlock
situation in advance. A method like "wait for graph" is used for
detecting the deadlock situation but this method is suitable only for
the smaller database. For the larger database, deadlock prevention
method can be used.

Deadlock Detection

In a database, when a transaction waits indefinitely to obtain a lock,

then the DBMS should detect whether the transaction 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
• In this method, a graph is created based on the transaction and their
lock. If the created graph has a cycle or closed loop, then there is a
deadlock.
• The wait for the graph is maintained by the system for every
transaction which is waiting for some data held by the others. The
system keeps checking the graph if there is any cycle in the graph.

26
 4/3/2025

Graph based protocol

The wait for a graph for the above scenario is shown below:

Deadlock Prevention

• Deadlock prevention 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.
• The Database management system analyzes the operations of the
transaction whether they can create a deadlock situation or not. If
they do, then the DBMS never allowed that transaction to be
executed.

27
 4/3/2025

Wait-Die scheme
If a transaction requests for a resource which is already held with a conflicting
lock by another transaction then the DBMS simply checks the timestamp of
both transactions. It allows the older transaction to wait until the resource is
available for execution.
Let's assume there are two transactions Ti and Tj and let TS(T) is a timestamp
of any transaction T. If T2 holds a lock by some other transaction and T1 is
requesting for resources held by T2 then the following actions are performed by
DBMS:
1. Check if TS(Ti) < TS(Tj) - If Ti is the older transaction and Tj has held
some resource, then Ti is allowed to wait until the data-item is available for
execution. That means if the older transaction is waiting for a resource which is
locked by the younger transaction, then the older transaction is allowed to wait
for resource until it is available.
2. Check if TS(Ti) < TS(Tj) - If Ti is older transaction and has held some
resource and if Tj is waiting for it, then Tj is killed and restarted later with the
random delay but with the same timestamp.

Wound wait scheme

if the older transaction requests for a resource which is held by the

younger transaction, then older transaction forces younger one to kill
the transaction and release the resource. After the minute delay, the
younger transaction is restarted but with the same timestamp.
If the older transaction has held a resource which is requested by the
Younger transaction, then the younger transaction is asked to wait
until older releases it.

28