UNIT – 4 DBMS NOTES 2025

Introduction to Transaction Processing

Concepts and Theory
Topics Covered:
➢ Introduction
➢ Introduction to Transaction processing
Single user versus Multiuser systems
Transactions, Database Items, Read and Write Operations and DBMS
Buffers.
Why concurrency control is needed
Why Recovery is needed
➢ Transactions and System concepts
Transaction states and Additional operations
System log
Commit point of a transaction
➢ Desirable properties of transactions
➢ Characterizing Schedules based on Recoverability
➢ Characterizing Schedules based on Serializability.
1.1 Introduction to Transaction Processing:
5.1.1 Single-User versus Multiuser Systems:
Database can be classified into
various type based on several criteria, such as the data model, number of
user it supports and database distribution.
A single-user database system - supports one user at a time can use the
system and a multiuser database system - supports multiple users can use
system concurrently. In Single-user DBMSs are restricted to personal
computer systems; most other DBMSs are multiuser. For example: An airline
reservations system is used by hundreds of travel agents (reservation clerks)
concurrently. Database systems used in banks, insurance agencies, stock
exchanges, supermarkets, and many other applications are multiuser systems.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 1

 UNIT – 4 DBMS NOTES 2025
In these systems, hundreds or thousands of users are typically operating on
the database by submitting transactions concurrently to the system.
In multi user database system, multiple users can access databases and use
computer systems simultaneously because of the concept of
multiprogramming.
Multiprogramming is a simple form of parallel processing in which several
programs are run at the same time on a single processor. Multiprogramming
allows the operating system of the computer to execute multiple programs or
processes at the same time.
Some of the characteristics of multiprogramming are,
• Multiprogramming is the allocation of more than one concurrent program
on a computer system and its resources.
• Multiprogramming allows using the CPU effectively by allowing various
users to use the CPU and I/O devices effectively.
• Multiprogramming makes sure that the CPU always has something to
execute, thus increases the CPU utilization.
Example of multiprogramming: Use a browser, play video, download apps
and transfer data at the same time.
But, single central processing unit (CPU) can only execute at most one process
at a time. However, multiprogramming, execute some commands from one
process, then suspend that process and execute some commands from the next
process, and so on. A process is resumed at the point where it was suspended
whenever it gets its turn to use the CPU again. Hence, concurrent execution of
processes is called interleaved, as illustrated in Figure below.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 2

 UNIT – 4 DBMS NOTES 2025

In the above figure shows two processes, A and B, executing concurrently in an

interleaved fashion. Interleaving keeps the CPU always busy, when a process
requires an input or output (I/O) operation, such as reading a block from disk.
The CPU is switched to execute another process rather than remaining idle
during I/O time. Interleaving also prevents a long process from delaying other
processes.
If the computer system has multiple hardware processors (CPUs), parallel
processing of multiple processes is possible, as illustrated by processes C and
D in above Figure 21.1.
Most of the theory concerning concurrency control in databases is developed in
terms of interleaved concurrency, so for the remainder of this chapter we
assume this model. In a multiuser DBMS, the stored data items are the
primary resources that may be accessed concurrently by interactive users or
application programs, which are constantly retrieving information from and
modifying the database.
5.1.2 Transactions, Database Items, Read and Write Operations, and
DBMS Buffers:
In a single-user application, the user can modify data without concern
for other users modifying the same data at the same time. However, in a multi-user
application, the statements within multiple simultaneous transactions can update the

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 3

 UNIT – 4 DBMS NOTES 2025
same data. Transactions executing at the same time need to produce meaningful and
consistent results.
Therefore, a multi-user application must provide the following:
Data concurrency: This ensures that multiple users can access data at the
same time.
Data consistency: which ensures that each user sees a consistent view of the
data, including visible changes made by the user's own transactions and
committed transactions of other users.
What is a Transaction?
A transaction is an action or series of action, which
occurs on the database. It provides a mechanism for describing database
processing operations such as read -retrieval, write - insert or update, delete
(reads a value from the database or writes a value to the database).
A transaction is typically implemented by a computer program unit whose
execution may or may not change the contents of a database. It means, a
transaction includes database commands such as retrievals, insertions,
deletions, and updates to ensure correctness of the database. 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 state.
For example, some of the transactions at a bank may be withdrawal or deposit
of money; transfer of money from A’s account to B’s account etc. A transaction
would involve manipulation of one or more data values in a database. Thus, it
may require reading and writing of database value.
Example:
Suppose a customer goes to the ATM and instructs it to transfer Rs.
1000 from its account (Account ‘A’) to his father’s account (Account ‘B’). This
simple transaction requires two steps:
➢ Subtracting the money i.e. Rs. 1000 from his account balance (from
Account A).
➢ Adding the money i.e. Rs. 1000 to his father’s account (from Account B)

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 4

 UNIT – 4 DBMS NOTES 2025
Simple Transaction Example:
1. Read account balance
2. Deduct the amount from balance
3. Write the remaining balance to account
4. Read account balance
5. Add the amount to account balance
6. Write the new updated balance to account
X's Account
1. Open_Account(X)
2. Old_Balance = [Link]
3. New_Balance = Old_Balance - 800
4. [Link] = New_Balance
5. Close_Account(X)
Y's Account
1. Open_Account(Y)
2. Old_Balance = [Link]
3. New_Balance = Old_Balance + 800
4. [Link] = New_Balance
5. Close_Account(Y)
To specify any transaction to performing database operation, we must specify
the transaction boundaries by specifying explicit begin transaction and end
transaction statements in an application program. In this case, all database
access operations between the two are considered as one transaction.
A single application program may contain more than one transaction if it
contains several transaction boundaries.
The example of the withdrawal transactions can be written in pseudo code as
follows:
TRANSACTION (A, B, transfer_amount)
Begin transaction
IF A AND B exist then
READ A’s Acct. balance

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 5

 UNIT – 4 DBMS NOTES 2025
IF A’s balance > transfer_amount THEN
A’s balance = A’s balance – transfer_amount
READ B’s Acct. balance
B’s balance = B’s balance + transfer_amount
COMMIT
ELSE DISPLAY (“Insufficient Balance in Account A”)
ROLLBACK
ELSE DISPLAY (“ACCOUNT A OR B DOES NOT EXIST”)
End_transaction
So, here the set of subtraction and addition operation is called a single
transaction. Likewise withdraw of money from bank account or any single or
set of operation perform in the database for a particular task is called
transaction. If a transaction involving only data retrieval without any data
update is called read-only transaction.
Here in the above pseudo code two keyword i.e. COMMIT and ROLLBACK has
been used. Commit makes sure that all the changes made by transactions are
made permanent. ROLLBACK terminates the transactions and rejects any
change made by the transaction.
Operations of Transaction:
Basically there are six operation takes place in a
transaction that is
➢ Begin transaction
➢ Read operation
➢ Write operation
➢ End transaction
➢ Rollback and Commit
Operations Descriptions
Retrieve To retrieve data stored in a database.
Insert To store new data in database.
Delete To delete existing data from database.
Update To modify existing data in database.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 6

 UNIT – 4 DBMS NOTES 2025
Commit To save the work done permanently.
Rollback To undo the work done.
Begin Transaction: it is a sign that indicates the start of a transaction
execution.
Read operation: it is used to read the value from the database and stores it in
a buffer in main memory.
Write Operation: it is used to write the value back to the database from the
buffer.
End transaction: it is the symbol that indicates end of a transaction.
Commit: it makes sure that all the changes made by transactions are made
permanent.
Rollback: it’s a Sign to specify that the transaction has been unsuccessful and
terminates the transactions and rejects any change made by the transaction. A
committed transaction cannot be rolled back.
Read (Retrieve) and Write (Insert or Update) operations are most common
operations in each transaction.
The database operations of each transaction can either be embedded within an
application program or they can be specified interactively via a high-level query
language such as SQL.
If the database operations in a transaction do not update the database but only
retrieve data, this type of transaction is called a read-only transaction;
otherwise it is known as a read-write transaction.
Read Operation (Read(X)): Read operation is used to read the value of X from
the database and stores it in a buffer in main memory. To read a database
object (item), it is first bring into main memory from disk, and then its value is
copied into a program variable as shown in figure.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 7

 UNIT – 4 DBMS NOTES 2025

Executing a read_item(X) command includes the following steps:

1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is not
already in some main memory buffer).
3. Copy item X from the buffer to the program variable named X.
Write Operation (Write(X)): Write operation is used to write the value back to
the database from buffer. Writes the value of program variable X into the
database item named X. [To write a database object, an in-memory copy of the
object is first modified and then written to disk.]

Executing a write_item(X) command includes the following steps:

1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is not
already in some main memory buffer).
3. Copy item X from the program variable named X into its correct location in
the buffer.
4. Store the updated block from the buffer back to disk (either immediately or
at some later point in time).

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 8

 UNIT – 4 DBMS NOTES 2025
Example:
Consider the debit transaction from an account which consists of
following operations:
1. R(X);
2. X = X - 500;
3. W(X);
Let's assume the value of X before starting of transaction is 4000.
o First operation reads X's value from database and stores it in a buffer.
o Second operation will decrease the value of X by 500. So buffer will contain
3500.
o Third operation will write the buffer's value to database. So X's final value
will be 3500.
A database is basically represented as a collection of named data items. The
size of a data item is called its granularity. A data item can be a database
record, but it can also be a larger unit such as a whole disk block, or even a
smaller unit such as an individual field (attribute) value of some record in the
database.
The transaction processing concepts we discuss are independent of the data
item granularity (size) and apply to data items in general. Each data item has a
unique name, but this name is not typically used by the programmer; rather, it
is just a means to uniquely identify each data item.
DBMS Buffer: A data buffer is an alternate and temporary location to store
data it is while being moved from one location to another. A buffer contains
data that is stored for a short amount of time, typically in the computer's
memory (RAM). The purpose of a buffer is to hold data right before it is used.
For example, when you download an audio or video file from the Internet, it
may load the first 20% of it into a buffer and then begin to play. While the clip
plays back, the computer continually downloads the rest of the clip and stores
it in the buffer. Because the clip is being played from the buffer, not directly
from the Internet, there is less of a chance that the audio or video will stall or
skip when there is network congestion.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 9

 UNIT – 4 DBMS NOTES 2025

Why Concurrency Control Is Needed:

What is concurrency control?
Concurrency control is the process of managing simultaneous execution of
transactions (managing simultaneous operations on the database) such as
queries, updates, inserts, deletes and so on in a multiprocessing database
system without having them interfere with one another.
[• Prevents interference when two or more users are accessing database
simultaneously and at least one is updating data.
• Although two transactions may be correct in themselves, interleaving of
operations may produce an incorrect result.]
When multiple transactions execute concurrently in an uncontrolled or
unrestricted manner, then it might lead to several problems. Such problems
are called as concurrency problems.
For example: In airline reservations database in which a record is stored for
each airline flight. Each record includes the number of reserved seats on that
flight as a named (uniquely identifiable) data item, among other information.

Above figure 21.2(a) shows a transaction T1 that transfers N reservations from

one flight whose number of reserved seats is stored in the database item
named X to another flight whose number of reserved seats is stored in the
database item named Y.
Figure 21.2(b) shows a simpler transaction T2 that just reserves M seats on the
first flight (X) referenced in transaction T1.
Concurrency problems are classified into four types. They are

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 10

 UNIT – 4 DBMS NOTES 2025

1. Dirty Read Problem

2. Unrepeatable Read Problem
3. Lost Update Problem
4. Phantom read Problem
Lost Update Problem: This problem occurs when two transactions that access
the same database items have their operations interleaved in a way that makes
the value of some database items incorrect.
In other words, if transactions T1 and T2 both read a record and then update
it, the effects of the first update will be overwritten by the second update.
Lost update problem occurs when two or more transactions are updating same
data items simultaneously. The transaction (among the concurrent
transactions) that commits at last (lately) will decide the final value of that
particular data item.

Suppose that transactions T1 and T2 are submitted at approximately the same

time, and suppose that their operations are interleaved as shown in Figure
21.3(a); then the final value of item X is incorrect because T2 reads the value of
X before T1 changes it in the database, and hence the updated value resulting
from T1 is lost.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 11

 UNIT – 4 DBMS NOTES 2025
Temporary Update (or dirty Read) Problem: This problem occurs when one
transaction updates a database item and then the transaction fails for some
reason (see Section 21.1.4).Meanwhile, the updated item is accessed (read) by
another transaction before it is changed back to its original value.
When one transaction can see intermediate results of another transaction
before it has committed.

Figure 21.3(b) shows an example where T1 updates item X and then fails
before completion, so the system must change X back to its original value.
Before it can do so, however, transaction T2 reads the temporary value of X,
which will not be recorded permanently in the database because of the failure
of T1. The value of item X that is read by T2 is called dirty data because it has
been created by a transaction that has not completed and committed yet;
hence, this problem is also known as the dirty read problem.
Incorrect Summary / Inconsistent Analysis problem:
If one transaction is calculating
an aggregate summary function on a number of database items while other
transactions are updating some of these items, the aggregate function may
calculate some values before they are updated and others after they are
updated.
For example, suppose that a transaction T3 is calculating the total number of
reservations on all the flights; meanwhile, transaction T1 is executing. If the
PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 12
 UNIT – 4 DBMS NOTES 2025
interleaving of operations shown in Figure 21.3(c) occurs, the result of T3 will
be off by an amount N because T3 reads the value of X after N seats have been
subtracted from it but reads the value of Y before those N seats have been
added to it.

Unrepeatable Read Problem: Another problem that may occur is called

unrepeatable read, where a transaction T reads the same item twice and the
item is changed by another transaction Tbetween the two reads.
Phantom Read Problem: If a transaction reads some variable from buffer and
when it reads the same variable later, it finds that the variable actually does
not exist, then this problem is known as Phantom Read Problem.
It is shocking for the transaction and it wonders where the variable has gone
when it has not deleted it because according to it, it is executing alone in
isolation.
Example:

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 13

 UNIT – 4 DBMS NOTES 2025
T1 reads X and then T2 reads X.
1. T1 deletes X.
2. Now, T2 tries reading X but does not find it.
Transaction T2 wonders where the variable X has gone when it has not deleted
it because according to it, it is running in isolation.
Why Recovery Is Needed:
Whenever a transaction is submitted to a
DBMS for execution, the system is responsible for making sure that either all
the operations in the transaction are completed successfully and their effect is
recorded permanently in the database, or that the transaction does not have
any effect on the database or any other transactions.
In the first case, the transaction is said to be committed, whereas in the
second case, the transaction is aborted.
The DBMS must not permit some operations of a transaction T to be applied to
the database while other operations of T are not, because the whole transaction
is a logical unit of database processing. If a transaction fails after executing
some of its operations but before executing all of them, the operations already
executed must be undone and have no lasting effect.
Types of Failures:
Failures are generally classified as transaction, system, and media
failures. There are several possible reasons for a transaction to fail in the
middle of execution:

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 14

 UNIT – 4 DBMS NOTES 2025
➢ A computer failure (system crash): A hardware, software, or network
error occurs in the computer system during transaction execution.
Hardware crashes are usually media failures.
For example: main memory failure.
➢ A transaction or system error: Some operation in the transaction may
cause it to fail, such as integer overflow or division by zero. Transaction
failure may also occur because of erroneous parameter values or because of
a logical programming error. Additionally, the user may interrupt the
transaction during its execution.
➢ Local errors or exception conditions detected by the transaction:
During transaction execution, certain conditions may occur that
necessitate cancellation of the transaction.
For example: data for the transaction may not be found. An exception
condition, such as insufficient account balance in a banking database, may
cause a transaction, such as a fund withdrawal, to be canceled. This
exception could be programmed in the transaction itself, and in such a case
would not be considered as a transaction failure.
➢ Concurrency control enforcement: The concurrency control method (see
Chapter 22) may decide to abort a transaction because it violates
serializability (see Section 21.5), or it may abort one or more transactions to
resolve a state of deadlock among several transactions (see Section 22.1.3).
Transactions aborted because of serializability violations or deadlocks are
typically restarted automatically at a later time.
➢ Disk failure. Some disk blocks may lose their data because of a read or
write malfunction or because of a disk read/write head crash. This may
happen during a read or a write operation of the transaction.
➢ Physical problems and catastrophes. This refers to an endless list of
problems that includes power or air-conditioning failure, fire, theft,
sabotage, overwriting disks or tapes by mistake, and mounting of a wrong
tape by the operator.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 15

 UNIT – 4 DBMS NOTES 2025
Failures of types 1, 2, 3, and 4 are more common than those of types 5 or 6.
Whenever a failure of type 1 through 4 occurs, the system must keep sufficient
information to quickly recover from the failure.
Disk failure or other catastrophic failures of type 5 or 6 do not happen
frequently; if they do occur, recovery is a major task.
Data recovery: Data recovery is the process of restoring data that has been
lost, accidentally deleted, corrupted or made inaccessible. Recovery from
transaction failures usually means that the database is restored to the most
recent consistent state just before the time of failure.
We discuss recovery from failure in Chapter 23.
The concept of transaction is fundamental to many techniques for concurrency
control and recovery from failures.
5.2 Transaction and System Concepts:
In this section we discuss additional concepts related
to transaction processing. Section 21.2.1 describes the various states a
transaction can be in, and discusses other operations needed in transaction
processing. Section 21.2.2 discusses the system log, which keeps information
about transactions and data items that will be needed for recovery. Section
21.2.3 describes the concept of commit points of transactions, and why they
are important in transaction processing.
5.2.1 Transaction States and Additional Operations:
A transaction is an atomic unit (or logical unit)
of work that should either be completed in its entirety or not done at all. For
recovery purposes, the system needs to keep track of when each transaction
starts, terminates, and commits or aborts. Therefore, the recovery manager of
the DBMS needs to keep track of the following operations:
BEGIN_TRANSACTION: This marks the beginning of transaction execution.
READ or WRITE: These specify read or write operations on the database items
that are executed as part of a transaction.
END_TRANSACTION: This specifies that READ and WRITE transaction
operations have ended and marks the end of transaction execution. However,

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 16

 UNIT – 4 DBMS NOTES 2025
at this point it may be necessary to check whether the changes introduced by
the transaction can be permanently applied to the database (committed) or
whether the transaction has to be aborted because it violates serializability (see
Section 21.5) or for some other reason.
COMMIT_TRANSACTION: This signals a successful end of the transaction so
that any changes (updates) executed by the transaction can be safely
committed to the database and will not be undone.
ROLLBACK (or ABORT): This signals that the transaction has ended
unsuccessfully, so that any changes or effects that the transaction may have
applied to the database must be undone.
A transaction in a database can be in one of the following states:
➢ Active
➢ Partially committed
➢ Failed
➢ Aborted
➢ Committed
Active state: Initial state:
This is the first state of transaction and here the transaction
is being executed. For example, updating or inserting or deleting a record is
done here. But it is still not saved to the database.
The transaction starts executing from the first instruction begin_transaction,
the transaction will be considered in active state. During this state it performs
operations READ and WRITE on some data items.
From active state, a transaction can go into one of two states, a partially
committed state or a failed state.

Partially committed state – After the execution of final statement:

This is the state of a transaction that successfully executing its last
or final instruction. That means, if an active transaction reaches and executes
the COMMIT statement, then the transaction is said to be in partially
committed state.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 17

 UNIT – 4 DBMS NOTES 2025
In the partially committed state, a transaction executes its final operation but
the data is still not saved to the database.
Example:- In the total mark calculation example, final display of the total
marks step is executed in this state.
Committed – After successful completion of transaction:
A transaction is said to be in a committed state
successfully, executes all its operations without fail. And all the transactions
are permanently saved to the database. This step is the last step of a
transaction.
NOTE:
• After a transaction has entered the committed state, it is not possible to roll
back the transaction i.e. we cannot undo the changes the transaction has
made because the system has been now updated into a new consistent state.
• We cannot abort or rollback a committed transaction.
• From committed state, a transaction can go into terminated state.

Failed – If any failure occurs:

If a transaction cannot proceed to the execution state
because of the failure of the system or database, then the transaction is said to
be in failed state.
While a transaction is in the active state or in the partially committed state, the
issues like transaction failure, user aborting the transaction, concurrency
control issues, or any other failure, would happen. If any of these issues are
raised, then the execution of the transaction can no longer proceed. At this
stage a transaction will go into a failed state.
Example of total mark calculation, if the database is not able to fire a query to
fetch the marks then the transaction will fail to execute. From failed state, a
transaction can go into only aborted state.
Aborted – After rolled back to the old consistent state:
If a transaction is failed to execute, then the
database recovery system will make sure that the database is in its previous

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 18

 UNIT – 4 DBMS NOTES 2025
consistent state. If not, it brings the database to consistent state by aborting or
rolling back the transaction. If the transaction fails in the middle of the
transaction, all the executed transactions are rolled back to it consistent state
before executing the transaction. Once the transaction is aborted it is either
restarted to execute again or fully killed by the DBMS.
After the failed state, all the changes made by the transaction has to be rolled
back and the database has to be restored to its state prior to the start of the
transaction. If these actions are completed by the DBMS then the transaction
considered to be in aborted state.
From aborted state, a transaction can go into terminated state
Terminated state:
This is the last state in the life cycle of a transaction. After entering
the committed state or aborted state, the transaction then finally enters into
a terminated state where the transaction life cycle finally comes to an end.

Example:
Let us assume a transaction T1 that transfers money from account A to
account B. Before transaction let A = 1000 and B = 1000. The transaction can
be represented as follows;
Transaction T1
BEGIN TRANSACTION
READ(A);
A := A - 500;

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 19

 UNIT – 4 DBMS NOTES 2025
WRITE(A);
READ(B);
B := B + 500;
WRITE(B);
COMMIT;
END TRANSACTION;
ACTIVE - When the transaction T1 starts, i.e., enters BEGIN TRANSACTION,
the transaction in ACTIVE state. From BEGIN TRANSACTION and COMMIT,
the transaction is in ACTIVE state only.
In ACTIVE state, A = 1000 and B = 1000.
PARTIALLY COMMITTED - If T1 reaches the instruction COMMIT, the
transaction goes into PARTIALLY COMMITTED state. In PARTIALLY
COMMITTED state, A = 500 and B = 1500;
FAILED – It happens if one of the following occurs;
If any failures happen to the transaction in ACTIVE state (refer type of failures)
then the transaction goes into FAILED state.
1. If the transaction failed before WRITE (A), then A = 1000 and B = 1000.
2. If the transaction failed after WRITE (A), then A = 500 and B = 1000.
3. If the transaction failed before COMMIT and after WRITE (B), then A = 500
and B = 1500.
4. If any failures happen to the transaction in PARTIALLY COMMITTED state
(refer type of failures) then the transaction goes into FAILED state.
5. If the transaction goes into FAILED state from PARTIALLY COMMITTED
state, then A = 500 and B = 1500.
ABORTED - The transaction in ABORTED state has to undo the changes made
so far. That is the old consistent values of data items A and B are restored.
In ABORTED state, A = 1000 and B = 1000. [A and B are rolled back to Old
consistent state]
COMMITTED - If the transaction executes COMMIT successfully, that is, if it
successfully writes the new value of A and B into log file or stable storage, then
the transaction is said to be in COMMITTED state.
In COMMITTED state, A = 500 and B = 1500. [New consistent state]

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 20

 UNIT – 4 DBMS NOTES 2025
5.2.2 The System Log:
To be able to recover from failures that affect
transactions, the system maintains a log to keep track of all transaction
operations that affect the values of database items, as well as other transaction
information that may be needed to permit recovery from failures.
The log is a sequence of records, append-only file, which maintains the records
of actions performed by a transaction that is kept on disk, so it is not affected
by any type of failure except for disk or catastrophic failure. Typically, one (or
more) main memory buffers hold the last part of the log file, so that log entries
are first added to the main memory buffer. When the log buffer is filled, or
when certain other conditions occur, the log buffer is appended to the end of
the log file on disk. In addition, the log file from disk is periodically backed up
to archival storage (tape) to guard against catastrophic failures. The following
are the types of entries called log records that are written to the log file and
the corresponding action for each log record. In these entries, T refers to a
unique transaction-id that is generated automatically by the system for each
transaction and that is used to identify each transaction:
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.
[start_transaction, T] Indicates that transaction T has started execution.
• When the transaction modifies an item X, it write logs as follows:
[write_item, T, X, old_value, new_value] Indicates that transaction T has
changed the value of database item X from old_value to new_value.
[read_item, T, X] Indicates that transaction T has read the value of database
item X.
[commit, T] Indicates that transaction T has completed successfully, and
confirm that its effect can be committed (recorded permanently) to the
database.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 21

 UNIT – 4 DBMS NOTES 2025
• When the transaction finishes, it logs:
[abort, T]. Indicates that transaction T has been aborted.
Desirable Properties of Transactions:
In order to guarantee the integrity of the DBMS, the integrity of the
transaction's ACID properties must be maintained. A transaction has four
basic properties which is also called ACID property.
ACID (atomicity, consistency, isolation, durability) is a set of properties that
guarantee that database transactions are processed reliably.
Atomicity (all or nothing):
A transaction is an atomic unit of processing; it
should either be performed in its entirety or not performed at all (either a
transaction will be done completely or not at all).
Atomicity requires that database modifications must follow an all or nothing
rule. Each transaction is said to be atomic if when one part of the transaction
fails, the entire transaction fails and database state is left unchanged.
Example: Consider banking system. Suppose Account A has a balance of
Rs. 400 & B has Rs. 700. Account A is transferring Rs. 100 to Account B. This
is a transaction that has two operations:
a) Debiting Rs. 100$ from A’s balance
b) Crediting Rs. 100$ to B’s balance.
Let’s say first operation passed successfully while second failed, in this case
A’s balance would be 300$ while B would be having 700$ instead of 800$. This
is unacceptable in a banking system. Either the transaction should fail
without executing any of the operation or it should process both the
operations. The Atomicity property ensures that.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 22

 UNIT – 4 DBMS NOTES 2025
If the transaction fails after completion of T1 but before completion of T2.( say,
after write(X) but before write(Y)), then amount has been deducted from X but
not added to Y. This results in an inconsistent database state. Therefore, the
transaction must be executed in entirety in order to ensure correctness of
database state.
Consistency (No violation of integrity constraints): The database must
remain in a consistent state after any transaction. No transaction should have
any adverse effect on the data residing in the database. If the database was in a
consistent state before the execution of a transaction, it must remain
consistent after the execution of the transaction as well. If a transaction fails
even then the database should come back to a consistent state.
A transaction must maintain 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.
This means that integrity constraints must be maintained so that the database
is consistent before and after the transaction.
For example account A is having a balance of 400$ and it is transferring 100$
to account B & C both. So we have two transactions here. Let’s say these
transactions run concurrently and both the transactions read 400$ balance, in
that case the final balance of A would be 300$ instead of 200$. This is wrong.
If the transaction were to run in isolation then the second transaction would
have read the correct balance 300$ (before debiting 100$) once the first
transaction went successful.
▪ For Example, T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A)
executing concurrently, the database reaches inconsistent state.
▪ Let us assume Account balance of A is Rs. 5000. T1 reads A(5000) and
stores the value in its local buffer space. Then T2 reads A(5000) and also
stores the value in its local buffer space.
▪ T1 performs A=A-1000 (5000-1000=4000) and 4000 is stored in T1 buffer
space. Then T2 performs A=A+500 (5000+500=5500) and 5500 is stored in
T2 buffer space. T1 writes the value from its buffer back to database.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 23

 UNIT – 4 DBMS NOTES 2025
▪ A’s value is updated to 4000 in database and then T2 writes the value from
its buffer back to database. A’s value is updated to 5500 which shows that
the effect of debit transaction is lost and database has become inconsistent.
To maintain consistency of database, we need concurrency control
protocols
T1 T1’s buffer space T2 T2’s Buffer Space Database
A=5000
R(A); A=5000 A=5000
A=5000 R(A); A=5000 A=5000
A=A-1000; A=4000 A=5000 A=5000
A=4000 A=A+500; A=5500
W(A); A=5500 A=4000
W(A); A=5500
Isolation: (concurrent changes invisibles):
The isolation property states that
the updates of a transaction should not be visible till they are committed.
Isolation refers to the requirement that other operations cannot access or see
data that has been modified during a transaction that has not yet completed.
Each transaction must remain unaware of other concurrently executing
transactions, except that one transaction may be forced to wait for the
completion of another transaction that has modified data that the waiting
transaction requires.
For example: Consider another transaction T2, which has to display the sum
of account A and B. Then, its result should be Rs.3000.
Let’s suppose that both Tl and T2 perform concurrently, their schedule is
shown below:

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 24

 UNIT – 4 DBMS NOTES 2025

The above schedule results inconsistency of database and it shows Rs.2950 as

sum of accounts A and B instead of Rs.3000. The problem occurs because
second concurrently running transaction T2, reads A and B at intermediate
point and computes its sum, which results inconsistent value. Isolation
property demands that the data used during the execution of a transaction
cannot be used by a second transaction until the first one is completed.
A solution to the problem of concurrently executing transaction is to execute
each transaction serially 'that is one after the other. However, concurrent
execution of transaction provides significant performance benefits, so other
solutions are developed they allow multiple transactions to execute
concurrently.
Durability (committed update persists): 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 database should be durable enough to hold all its latest updates even if
the system fails or restarts.
Durable: Once database has committed a transaction, the changes made by
the transaction should be permanent. e.g.; If a person has credited $500000 to
his account, bank can’t say that the update has been lost. To avoid this
problem, multiple copies of database are stored at different locations.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 25

 UNIT – 4 DBMS NOTES 2025
What is Schedule?
As we know a transaction is a collection of or set of or
sequence of instructions that perform a logical work. When more than one
transactions are executing parallel the order of execution of various
instructions is called as a schedule.
A schedule is important in a database transaction because when more than
one transactions execute in parallel, they may alter the result of the
transaction means if one transaction is updating the values which is in use by
the other transaction, then the order of these two transactions will change the
result of second transaction. Hence a schedule is created to execute the
transactions.
Types of Schedules
1. Serial Schedules
2. Non-serial Schedules
3. Serializable Schedules
Serial Schedules
The serial schedule is a type of schedule where the transactions are executed
one after another, i.e., a serial schedule is one in which no transaction starts
until a running transaction has ended are called serial schedules.
Suppose there are two transactions T1 and T2 having some operations. If these
two has no interleaving of operations, then there will be two possible results:
Execute all the instructions of T1 which was followed by all the operations of
T2.
Execute all the operations of T2 which was followed by all the operations of T1.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 26

 UNIT – 4 DBMS NOTES 2025
Here, in the above two schedule (1 and 2) are serial schedule because to the
transaction T1 and T2 are performed in serial order so they can execute in any
manner i.e. T1->T2 or T2->T1.
Non-serial Schedules
A schedule is said to be non-serial if interleaving of operations is allowed
means if the operations of more than one transaction are executed non-
consecutively and operations overlap at time.

Serializable Schedules
A schedule of n transactions is said to be serializable if it is equivalent to some
serial schedule of the same n transactions. In other words a non-serial
schedule will be serializable if its result is equal to the result of its transactions
executed serially.
A Non-serial schedules that are equivalent to one (or more) of the serial
schedules is called serializable, whereas that are not equivalent to any serial
schedule are called not serializable.
Then the question comes how to check whether it is serializable or not?
Serializability is a concept which is used to find which non-serial schedules are
correct and will maintain the consistency of the database.
Testing of Serializability
To determine serializability of a schedule the best and effective method is to
construct a directed graph, which is known as precedence graph of the
Schedule.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 27

 UNIT – 4 DBMS NOTES 2025
➢ If the directed graph or precedence graph contain a cycle then it is not
serializable or not conflict serializable.
➢ If the directed graph or precedence graph not contains a cycle then it is
serializable or conflict serializable.
Conflict serializability
A schedule is called conflict serializable if we can convert it into a serial
schedule after swapping its non-conflicting operations.

Conflicting operations

Two operations are said to be in conflict, if they satisfy all the following
three conditions:
1. Both the operations should belong to different transactions.
2. Both the operations are working on the same data item.
3. At least one of the operations is a write operation.
Instruction Ii and Ij of Transaction Ti and Tj respectively conflict if and only if
there exists some item Q, accessed by both Ii and Ij and atleast one of these
instructions wrote data item Q.
• if Ii = read(Q) and Ij = read(Q) then Ii and Ij don't conflict
• if Ii = read(Q) and Ij = write(Q) then Ii and Ij conflict
• if Ii = write(Q) and Ij = read(Q) then Ii and Ij conflict
• if Ii = write(Q) and Ij = write(Q) then Ii and Ij conflict
If a schedule can be transformed into a schedule S' by a series of swaps of non-
conflicting instructions, we say that S and S' are conflict equivalent.
We say that a schedule S is conflict serializable if it is conflict equivalent to
serial schedule
Algorithm: (Testing Serializability of a Schedule S)
The steps of constructing a precedence graph are:
1. Create a node for every transaction in the schedule.
2. Find the precedence relationships in conflicting operations. Conflicting
operations are (read-write) or (write-read) or (write–write) on the same data item
in two different transactions. But how to find them?

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 28

 UNIT – 4 DBMS NOTES 2025
2.1 For a transaction Ti which reads an item A, find a transaction Tj that writes
A later in the schedule. If such a transaction is found, draw an edge from Ti to
Tj.
2.2 For a transaction Ti which has written an item A, find a transaction Tj later
in the schedule that reads A. If such a transaction is found, draw an edge from
Ti to Tj.
2.3 For a transaction Ti which has written an item A, find a transaction Tj that
writes A later than Ti. If such a transaction is found, draw an edge from Ti to
Tj.
3. If there is any cycle in the graph, the schedule is not serializable, otherwise,
find the equivalent serial schedule of the transaction by traversing the
transaction nodes starting with the node that has no input edge.
Example:
Let us use this above algorithm to check whether a schedule is Serializable or
not.

Explanation:
Read(X): In T2, no subsequent writes to X, so no new edges
Read(X): X is subsequently Write by T1, so add edge T2 → T1
Write(X): In T2, no subsequent read/writes to X, so no new edges
Read(Y): Y is subsequently Write by T1, so add edge T2 → T1
Read(Y): In T2, no subsequent writes to Y, so no new edges

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 29

 UNIT – 4 DBMS NOTES 2025
Write(X): In T2, no subsequent read/writes to X, so no new edges

The transaction T2 reads dataitem X, which is subsequentlywritten by T1, thus

there is anedge from T2 to T1 as per clause2.1.

Then T2 reads data item Y, whichis subsequently written by T1,thus there is

an edge from T2 toT1 as per clause 2.1. As, that edgealready exists, so we do
not needto redraw the edge again.

Please note that there are no cycles in the graph, thus, the above schedule is
serialisable or conflict serialisable.
Example-03
Assume a schedule S as below

As per step 1, we draw the three nodes for T1 and T2 and T3.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 30

 UNIT – 4 DBMS NOTES 2025
Explanation:
Read(X): X is subsequently Write by T3, so add edge T1 → T3
Read(Z): Z is subsequently Write by T2, so add edge T3 → T2
Write(Z): Z is subsequently Write by T2, so add edge T3 → T2
Read(Y): In T1 or T3, no subsequent writes to Y, so no new edges
Read(Y): Y is subsequently Write by T2, so add edge T1 → T2
Write(Y): In T1 or T3, no subsequent writes to Y, so no new edges
Write(X): X is subsequently Write by T1, so add edge T3 → T1
Write(Z): In T1 or T3, no subsequent read/writes to Z, so no new edges
Write(X): In T2 or T3, no subsequent read/writes to X, so no new edges
Please note that the graph above contains a cycle, hence it is not serialisable or
not conflict serialisable.

PUTTASWAMY B. S. Assistant Professor, Dept. of CSBS, PESCE Mandya Page 31