DATABASE MANAGEMENT

SYSTEM
DBMS Group

Authors Gaurav Kansal, B P Sharma, Pratibha Singh,

Nidhi Singh, Anand Kr. Srivastava, Ritin Behl,
Sachin Goel
Authorized by
Creation/Revision Date July 2021
Version 1.0
Table of Contents
7.1 Concept of Transaction ........................................................................................................................ 3
7.1.1 Transaction in DBMS ..................................................................................................................... 3
7.1.2 Transactions States and various operations ................................................................................ 6
7.2 ACID Properties .................................................................................................................................... 8
7.3 Concept of concurrency...................................................................................................................... 11
7.4 Inconsistency problem due to concurrent execution ...................................................................... 14
7.4.1 Dirty Read Problem (W-R conflict) ............................................................................................... 14
7.4.2 Lost Update Problem (W-W conflict)............................................................................................ 15
7.4.3 Unrepeatable Read Problem (W-R conflict) ................................................................................. 16
7.4.4 Phantom Read Problem ................................................................................................................ 16
7.5 Serializability....................................................................................................................................... 17
7.5.1 Conflict Serializability .................................................................................................................... 24
7.5.2 View Serializability ........................................................................................................................ 27
7.6 Testing for Serializability ................................................................................................................... 29
7.7 Recoverability .................................................................................................................................... 35
7.8 Transaction Control using SQL ............................................................................................................. 43
7.1 Concept of Transaction

In general terms, a transaction can be defined as a logically related group of operations. A

single operation is the minimum processing unit that cannot be divided further.

Example 1:A teacher is marking the attendance of a student in the attendance system. The set
of operations would be like this:
1. Read the attendance record balance of a student of a subject.
2. Add the new attendance value to the attendance balance.
3. Write the newly updated attendance balance to the attendance record.

Example 2: A parent is transferring money from his bank account to a university bank account.
The set of operations would be like this:
1. Read parent’s account balance.
2. Deduct the amount from the parent's account balance
3. Write the remaining balance to the parent's account
4. Read university bank account balance
5. Add the amount to the university bank account balance
6. Write the newly updated balance to the university bank account

In the above examples, all the operations are logically related for a defined purpose and any
operation cannot be further subdivided into further sub-operations. Thus, in example 1,
“marking attendance of a student by a teacher” is one transaction and in example 2,
“transferring money from parent’s account to university account” is also one transaction.

7.1.1 Transaction in DBMS

In terms of DBMS, a transaction is the execution of a program, a sequence of operations

thataccesses or updates the contents of a database.
1. A transaction is a logical, atomic unit of work that contains one or more SQL statements.
2. The database operations that form a transaction can be embedded within an application
program or specified interactively via a high-level query language such as SQL.
3. The actions accomplished in a transaction contain one or multiple database actions such
as retrieve, insert, or update data.
4. A transaction on the database is either completed in its entiretyor not done at all. If the
database was in a consistent state before a transaction, then after execution of the
transaction, the database must be in a consistent state.
To understand the concept of transaction in DBMS, we focus on a simple model where data are
moved from disk to main memory and from main memory to disk. The only operations on the
data items are arithmetic operations and a name identifies each data item (typically a single
letter in our examples, that is, A, B, C, etc.) with a data value (a number in our examples)

Data Item: A database is represented as a collection of named data items. A data item can
be a database record, 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 data is accessed by transactions using two operations.

 read(X): This operation reads the value of data item X from the database server and
keeps it in a buffer in the main memory, as shown in Figure 7. 1

 write(X): This operation writes the value of data item X to the database server from the
buffer as shown in Figure 7. 2

Read Operation : read(X)

5000 Buffer (X)

Input
5000 Block (X)

Main Memory
Disk
Figure 7. 1: Read Operation
 Write Operation : write(X)

7000 Buffer (X)

Output
7000 Block (X)

Main Memory
Disk
Figure 7. 2: Write Operation

Block movements between disk and main memory are initiated through the following two
operations:
 Input(B) transfers the physical block B to the main memory
 Output(B) transfers the buffer block B to the disk and replaces the appropriate physical
block there.

Buffer:A buffer is a region of the main memory storage used to store data temporarily

Using our simple model, we write the above example like this:

In example 1, let's say the attendance record of a student is X; the steps of the transaction are:
1. read (X); (Retrieve the student attendance record X)
2. X = X + 2; (Adding the attendance value 2 to the attendance record)
3. write (X); (Updating the attendance value in student record X)

In example 2, your parent's account is A and your university account is B. You are transferring
Rs. 50000 from A to B, the steps of the transaction are:
1. read (A); (Retrieve the value of parent’s account A)
2. A = A - 50000; (Deduct the amount Rs. 50000 from parent’s account A)
3. write (A); (Updating the remaining balance to parent’s account A)
4. read (B); (Retrieve the value of university account B)
5. B = B + 50000; (Add the amount Rs. 50000 from parent’s account A)
6. write (B); (Updating the remaining balance to parent’s account A)
7.1.2 Transactions States and various operations

A transaction may be in many states during its lifetime. States of the transaction are the
situation and condition in which a transaction in DBMS is currently present. A particular
transaction can only be in one state at any given time. This transaction state helps us know
about the present situation in which the transaction is executing and will suggestthe system
and possible further states.The various operations performed by the transaction are mentioned
below:

 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, 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/undone because it violates serializability (explained in further sections) or for
some other reason.
 COMMIT. 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.

The followingFigure 7. 3 shows the state transition diagram, which shows how a transaction
moves through its execution states along with the operations:

Figure 7. 3: Representation of Operations and States of a Transaction

The various states are shown inFigure 7. 3are:

Active State:

The active state is the initial state, and a transaction is in it as soon as it begins. If a transaction
is in execution, it is said to be in an active state. A transaction contains the number of read and
write operations. All the Read and Write operations are executed by transaction in this state.All
the read and write operations are performed on the main memory (local memory) instead of
the actual database during this state.

Partially Committed State

After completing the various operations in Active State, when a transaction ends, it moves in a
partially committed state. In this state, some types of concurrency control protocols and
recovery protocols (to be discussed later in the chapter) may do additional checks on the read-
write operations performed in Active State to see if the transaction can be committed or not
and a system failure will not result in an inability to record the changes of the transaction
permanently.

Committed State

If a transaction completes the execution successfully, the checks performed in a partially

committed state are successful, the transaction is entered into Committed State. In this state,
all the changes maintained in the local memory during a partially committed state are
permanently stored in the database.

Failed State

If a transaction is executing and a failure occurs, either a hardware failure or a software failure,
the transaction is aborted from the active state or partially committed state and moves into a
failed state.
Also, transactions are moved to this state if any consistency checks performed in a partially
committed state fail.

Terminated State
Either the transaction comes from a “failed state" after rollback or the transaction comes from
the "committed state". Then, the system is consistent and ready for a new transaction and the
old transaction is terminated.
7.2 ACID Properties

ACID is a concept (and an acronym) that refers to the four properties of a transaction in a
database system: Atomicity, Consistency, Isolation, and Durability.
These properties ensure the accuracy and integrity of the data in the database, ensuring that
the data does not become corrupt due to some failure, guaranteeing the validity of the data
even when errors or failures occur.

The ACID properties allow us to write applications without considering the complexity of the
environment where the application is executed. These are essential for processing transactions
in databases. Because of the ACID properties, we can focus on the application logic instead of
failures, recovery, and data sync.

Atomicity:

In the context of databases, atomicity means that either:

 The execution of the transaction got completed and committed.
 No transaction at all means transaction is aborted.

A transaction must be an atomic unit of work, which means that all the modified data are
performed, or none of them will be. The transaction should be executed completely or fail. If
one part of the transaction fails, all the transactions will fail.Therefore, the transaction should
not occur partially.

In the above-mentioned example 2, let suppose parent account A has Rs. 70000 in his account
from which he needs to send Rs. 50000 to university account B. In account B, a sum of Rs.
100000 is already present. When Rs. 50000 is transferred to account B, the sum will become Rs.
150000.

In this transaction, there will be two operations that will take place to complete this
transaction.
1. The amount of Rs.50000 that the parent wants to transfer will be debited from his
account A
2. The same amount will get credited to college account B.

During the transaction, suppose the first operation of debit executes successfully, but the credit
operation fails. Thus, in parent account A, the value becomes Rs. 20000, and to that of college
account, it remains Rs. 10000 as it was previously present as shown in Figure 7. 4
 Figure 7. 4: Representation of a Fail Transaction

This is unacceptable in a banking system. Either the transaction should fail without executing
any of the operations, or it should process both operations. The atomicity property ensures that
the corresponding credit is made to the other account if a debit is made successfully from one
account.

Consistency:

A transaction should be consistency preserving, meaning that if it is completely executed from

beginning to end without interference from other transactions, it should take the database
from one consistent state to another.

In the above example, Account A and Account B have Rs. 100000 and Rs. 70000 respectively.
So, the total amount is Rs. 100000+ Rs. 70000, i.e., Rs. 170000 before the transaction. When
any transaction is executed, then the total amount should also be Rs. 170000. If the transaction
occurs, then Rs. 50000 will be deducted from Account A and added to Account B. The total
amount after the transaction will be Rs. 20000 + Rs. 150000 = Rs. 170000. So, this property
ensures the consistency of the database.

Another way of ensuring consistency within a database throughout each transaction is by

enforcing integrity constraints placed on the database.
For example, integrity constraint is defined as "accounts must have a positive balance".
Therefore, if a transaction brought any account into a negative balance, that transaction would
be rolled back.

Isolation:
This property tells us that a transaction should appear as though it is being executed in isolation
from other transactions, even though many transactions are executed concurrently. This
means, if more than one transaction is taking place in parallel, then the occurrence of one
transaction will not affect the other transaction. If any transaction is using a data item, then it
can't be used by other transactions until the first transaction ends.
Example: Suppose we have two transactions, T1 and T2, which are defined as follows.
In transaction T1, a parent is transferring an amount of Rs. 50000 from account A to university
account B. The initial balance of account A is Rs. 70000.
In transaction T2, the bank is adding the interest of 10% in account A.

Figure 7. 5: Representation of two parallel executing transactions

Now, consider a situation where T1 has been executed until A=A-50000 and then T2 starts. Due
to this, transaction T2 reads the incorrect value of A. It reads the value as 70000 and the
operations which should have been performed by taking the value as 20000, T2 will perform by
taking the value as 70000 as shown inFigure 7. 5.This leads to inconsistent results. For example,
the output of the transaction T2 should have been 20000 *.1 =2000, but it will produce the
output as 70000*.1 =7000 as T2 has read the incorrect value of A. This problem happened
because the transaction result of T1 was made available for T2. So to avoid any such problem,
the transactions take place in isolation.

Importantly, this doesn't mean two operations can't happen at the same time. On the contrary,
multiple transactions can occur as long as those transactions have no possibility of impacting
the other transactions simultaneously.

Doing this can impact the speed of transactions as it may force many operations to wait before
they can initiate. However, this tradeoff is worth the added data security provided by isolation.

Durability:
Durability ensures that changes made to the database (transactions) that are successfully
committed will survive permanently, even in the case of system failures. This ensures that the
data within the database will not be corrupted by:
 Service outages
  Crashes
 Other causes of failure
For example, in an application that transfers funds from one account to another, the durability
property ensures that the changes made to each account will not be reversed.

7.3 Concept of concurrency

The database system can be classified according to the number of users who can use the
system concurrently. A DBMS is a single-user if at most one user can use the system, and it is a
multi-user if many users can use the system simultaneously.This means the computer runs
multiple transactions (programs)at the same time.

For example, an airline reservations system is used by hundreds of travel agents and
reservation clerks concurrently. Systems in banks,insurance agencies, stock exchanges and the
like are also operated by manyusers who submit transactions concurrently to the system.

In a single-user database, the user can modify data in the database without concern for other
users modifying the same data at the same time. However, in a multi-user database, the
statements within multiple simultaneous transactions can update the same data.

When multiple transactions are trying to execute simultaneously, then there can be two
possible ways:
a. Serial or Sequential Execution of Transactions
b. Non-serial or Concurrent Execution of Transactions

Let understand the above-mentioned possible ways with the help of an example.

Suppose there are two students, S1 and S2, who are submitting their fees to college at the
same time (using web/mobile application). S1 is submitting Rs. 2000 in college account (X) and
S2 is submitting Rs. 3000 in college account (X). Assume they have already submitted Rs. 5000
and Rs. 10000 in the college account. Now there are two transactions T1 and T2, T1 transaction
contains the operations of fee submitting by student S1, and the T2 transaction contains the
operations of fee submitting by student S2. Both transactions, T1 and T2, are executing at the
same time means executing simultaneously.

In Serial/Sequential Execution, if transaction T1 will execute, transaction T2 has to wait till T1

complete its all operation as in Table 7. 1 And if transaction T2 will execute, transaction T1 has to
wait till T2 completes its all operation as in
Table 7. 2
 Table 7. 1: Serial or Sequential Execution of Transaction

Timestamp T1 T2 Remarks

1 read(X) T1 read X : 5000

2 X = X + 2000 Computed : X = 7000
3 write(X) T1 write X as 7000 in Temp buffer
4 Commit T1 update X : 7000 in database
5 read(X) T2 read X : 10000
6 X = X + 3000 Computed : X = 13000
7 write(X) T2 write Y : 13000 in Temp buffer
8 Commit T2 update Y : 13000 in database

Table 7. 2: Serial or Sequential Execution of Transaction

Timestamp T1 T2 Remarks

1 read(X) T2 read X : 10000

2 X = X + 3000 Computed : X = 13000
3 write(X) T2 write X as 13000 in Temp. buffer
4 Commit T2 update X : 13000 in database
5 read(X) T1 read X : 5000
6 X = X + 2000 Computed : X = 7000
7 write(X) T1 write X : 7000 in Temp. buffer
8 Commit T1 update X : 7000 in database

With the help of the above example, when multiple transactions are trying to execute at the
same time in serial or sequential order of execution, we can say that database will be 100 %
consistent. However, this approach of serial execution creates some serious issues like waiting
time of other transactions will increase, the response time of other transactions is increased,
resource utilization is less and in summary, system performance will be very poor.
To overcome these problems, we add the concept of concurrency and we use concurrent
execution of transactions. In this approach, each transaction gets a small time slot to complete
its operation in a cyclic manner, meaning the transactions' operations are interleaved with
respect to time.

Interleaving of operations: As there is only one CPU, only one program can be processed.To
avoid excessive delays, concurrent systems execute some operations fromone transaction, then
suspend that transaction and execute some operations from the next transaction, and so on. A
transaction is resumed at thepoint where it was suspended when it gets its turn to use the CPU
again. Thisis known as interleaving.

Here few possible concurrent executions of the above-mentioned example are shown below.
 Table 7. 3: Example-1 of Concurrency

Timestamp T1 T2

1 read(X)
2 read(X)
3 X = X + 2000
4 X = X + 3000
5 write(X)
6 write(Y)
7 Commit
8 Commit

Table 7. 4: Example-2 of Concurrency

Timestamp T1 T2

1 read(X)
2 X = X + 3000
3 read(X)
4 X = X + 2000
5 write(X)
6 write(X)
7 Commit
8 Commit

Table 7. 5: Example-3 of Concurrency

Timestamp T1 T2

1 read(X)
2 X = X + 2000
3 read(X)
4 X = X + 3000
5 write(X)
6 write(X)
7 Commit
8 Commit
 Table 7. 6: Example-4 of Concurrency

Timestamp T1 T2

1 read(X)
2 X = X + 2000
3 write(X)
4 read(X)
5 X = X + 3000
6 write(X)
7 Commit
8 Commit

In all the above-mentioned examples, various operations of the transactions T1 and T2 are
interleaved.

Using Concurrency or Concurrent Execution, we can achieve the following things –

(a) Low waiting time

(b) Low Response time
(c) High Resource Utilization
(d) High System performance

The problem with concurrency is the high risk of database inconsistency. This property of DBMS
allows many transactions to access the same database at the same time without interfering
with each other. The primary goal of concurrency control is to ensure the atomicity of the
execution of transactions in a multi-user database environment. Concurrency controls
mechanisms attempt to interleave READ and WRITE operations of multiple transactions in such
a manner that the interleaved execution yields identical results to the results of serial
execution.
Due to uncontrolled concurrency, a few inconsistency problems may create an inconsistent
database state, which is mentioned below.

7.4 Inconsistency problem due to concurrent execution

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

7.4.1 Dirty Read Problem (W-R Conflict)

The dirty read problem occurs when one transaction updates an item of the database, and
somehow the transaction fails. Before the data gets rollback, the updated database item is
accessed by another transaction. There comes the Read-Write Conflict between both
transactions.
In summary, we can say that when any transaction read other transaction updated and
uncommitted data value, it is called the Dirty Read problem.
Suppose one student is submitting the fee of Rs. 2000 to college (account X) and college
(Starting balance is Rs. 5000 in account X) is reading the account (to confirm the fee
submission). Here there are Two Transactions T1 and T2. T1 is for student's operation and T2 is
for college. One possible concurrent schedule is given in Table 7. 7
Table 7. 7: Dirty Read Problem

In the above example, Transaction T2 (college) is reading uncommitted and updated from
Transaction T1(student) data value; this is called Dirty Read Problem. Dirty Read Problem is also
called write-read (W-R) Conflict.

7.4.2 Lost Update Problem (W-W Conflict)

In the lost update problem, an update done to a data item by a transaction is lost as the
update done by another transaction overwrites it.
Suppose two transactions T1 and T2, are performed on the same account X where the initial
balance of account X is Rs. 5000 T1 adds Rs. 3000 more amount in account X and T2 deducting
Rs. 2000 amount from account X. let us consider the following executions shown inTable 7. 8.
Lost update problem is also called write-write (W-W) conflict.
 Table 7. 8: Lost Update Problem

Timestamp T1 T2 Remarks
Assume starting amout is Rs. 5000
1 read(X) Transaction T1 is reading X: 5000
2 X = X + 3000 T1 Adding in X : X = 8000
3 read(X) Transaction T2 is reading X i.e X: 5000
4 X = X - 2000 T2 deducting Rs. 2000 from X : i.e X = 3000
T1 write X in temp buffer X: 8000 as per timestamp 2
5 write(X)
because T2 did not update the value yet.
T2 write X in temp buffer X : 3000 as per timestamp 4. that
6 write(X) means the value written by T1 i.e X: 8000 at timestamp 5 is
lost.
Lost Update

T1 written value (X: 8000) is lost and updated by transaction T2 written value (X: 3000). Thus, in
the future, if transaction T1 reads X, it will read 3000 value, not 8000.

7.4.3 Unrepeatable Read Problem (W-R Conflict)

The unrepeatable problem occurs when two or more read operations of the same transaction
read different values of the same variable. It is also called write–read (W-R) conflict.

Suppose two transactions T1 and T2, performed some operation on data value X with the
following execution (Table 7. 9). The initial value ox X is 5000.
Table 7. 9: Unrepeatable read Problem

It means that within the same transaction T1, it reads two different values of X, i.e., 5000
initially, and after updation made by transaction T2, it reads 3000. Thus, it is an unrepeatable
read and is therefore known as the Unrepeatable read problem.

7.4.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.
Suppose two transactions T1 and T2, performed some operation on data value X with the
following execution shown inTable 7. 10. The initial value of X is 5000.
Table 7. 10: Phantom read Problem

In the above example, T2 reads the variable X, i.e., 5000 at time t1, T1 deletes the variable X
at time t2. Thus, T2 is unable to read X at time t3.
The above inconsistency problems occurred due to the concurrent execution of multiple
transactions. Now the question is – Are all concurrent (non-serial schedule) executions create
inconsistency problems? The answer is NO. Those non-serial schedules can be converted into
any one corresponding serial schedule cannot create inconsistency problem. Or we can say that
if any non-serial schedule consists of serializability features, then it is equivalent to serial
schedule and serial schedule cannot affect the consistency of the database. In the next topic,
we will see how we can check the existence of serializability features in any given schedule.

7.5 Serializability

In a multi-user system, multiple users can perform a sequence of different operations

simultaneously on the same database. When several transactions run concurrently, then
database consistency can be destroyed even though the execution of an individual transaction
is correct. In this section, we will discuss the concept of schedules, types of schedules (as shown
inFigure 7. 6) and also will identify those executions that guarantee to ensure consistency, i.e.,
the concept of serializability.
 Figure 7. 6: Types of schedule in DBMS

Let T1 and T2 be two transactions that transfer funds from one account to another. T 1 transfers
Rs. 36000 of student's academic fees from parents account (A) to University account (B). The
sequence of instructions of transaction T1 are as shown in Table 7. 11
Table 7. 11: Transaction T1

T2 transfers 10% of student's academic fee, i.e., Rs. 3600 to parents account (A) from University
account (B) as a scholarship amount. The sequence of instructions of transaction T2 is as shown
inTable 7. 12.
 Table 7. 12: Transaction T2

Suppose the current values of accounts A and B are Rs. 50000 and Rs. 800000 respectively. Let
us take the case where these two transactions (T1 and T2) are executed in the order T1 followed
by T2, as shown inTable 7. 13. T1 executes first andcompletes its execution before T2 starts. The
final values of accounts A and B after the execution are Rs. 17600 and Rs. 832400 respectively.
The total amount before the execution of these transactions is Rs. 850000 and after the
execution is also Rs. 850000.
Thus, the total amount of money in accounts A and B, that is, the sum A + B, is the same before
and after the execution of both transactions. Similarly, the execution sequence, when
instructions of T2 are followed by T1, is shown inTable 7. 14. It also preserves the sum of the
balance of accounts A and B.
Table 7. 13: Schedule A: T1 followed by T2
 Table 7. 14: Schedule B: T2 followed by T1

Schedule
A transaction is a set of instructions and each instruction performs an operation on the
database. When multiple transactions execute concurrently, then there is a need to order the
sequence of operations because only one operation can be performed on a database at a time.
The execution sequence of transactions T1 and T2, as described and shown in Table 7. 13 and Table
7. 14, are called as schedule.

A schedule is a sequence of instructions by a set of concurrent transactions T 1, T2, …, Tn that

preserves an ordering of the instructions of the individual transactions.

Note:
 A schedule represents the chronological order in which the instructions are executed in the
system.
 A schedule for a set of transactions must consist of all instructions for those transactions.
 For an individual transaction Ti in a schedule (S), the instructions of Ti in S must preserve the
order in which they appear in Ti.

Serial Schedule
In serial schedule, if there are two transactions T1 and T2 executing at the same time and if
interleaving of operations is not permitted, then instructions of each transaction executes
sequentially without any interleaved instruction of other transaction. There are two possible
ways of execution of the two transactions T1 and T2:
1. Execute all instructions of transaction T1 in sequence and is followed by execution of all
instructions of transaction T2. (T1 followed by T2 as shown inTable 7. 13)
2. Execute all instructions of transaction T2 in sequence and is followed by execution of all
instructions of transaction T1. (T2 followed by T1 as shown inTable 7. 14)
In simple words, in a serial schedule, a new transaction is started only after the previous
transaction is completed.
Non-Serial Schedule
When the database system executes multiple transactions concurrently, then the
corresponding schedule may no longer be serial. If two or more transactions are running
concurrently, then the operating system may execute one transaction for a little while, then
perform a context switch, and execute the other transaction for some time, and then switch
back to the first transaction for some time, and so on. The CPU time is shared among all the
transactions in this schedule. There will be several possible execution sequences since the
several instructions of different transactions may now be interleaved.
In non-serial schedules:

 Several transactions can execute concurrently.

 Instructions of multiple transactions are interleaved or mixed with each other.
 The concurrency-control component of the database system ensures that any schedule
that gets executed will leave the database in a consistent state.
A non-serial schedule or concurrent schedule with two transactions T 1 and T2, is shown in a
non-serial schedule inTable 7. 15 and Table 7. 16
Table 7. 15: Non-Serial schedule or Concurrent schedule

Table 7. 16: Non-Serial schedule or Concurrent schedule

Serializable Schedule:

We can see that scheduling of instructions in a concurrent schedule, as shown in Table 7. 15

reaches the consistent state. Scheduling of instructions in the concurrent schedule as shown
inTable 7. 16leave the database to the in-consistent state as the initial total sum of the balance of
accounts A and B is Rs. 850000, but at the end of this concurrent schedule total sum of the
balance of account A and B is Rs. 846400. Thus there is a requirement to preserve consistency
in the database.

Serializability is used to maintain the consistency of the database. It is mainly used in non-serial
scheduling to verify whether the scheduling in a set of transactions will lead to a consistent
state or not.

A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule. Suppose

S is a concurrent schedule and is logically equivalent to a serial schedule S’, then S is said to
be a serializable schedule.

This refers to a situation wherein the concurrent execution of two transactions (say T i and Tj) is
logically equivalent to their serial execution, i.e., either Ti followed by Tj or Tj followed by Ti. A
serializable schedule helps in improving both resource utilization and CPU throughput.

Table 7. 17: Serial Schedules Vs Serializable Schedules

Serial Schedules Serializable Schedules

No concurrency is allowed. Thus, all transactions Concurrency is allowed. Thus, multiple
execute one after the other in serial order. transactions can execute concurrently.
Serial schedules may lead to less resource Serializable schedules improve resource
utilization and less CPU throughput. utilization and CPU throughput.
Serial Schedules are less efficient as compared to Serializable Schedules are always better
serializable schedules. than serial schedules.

Importance of read and write instructions in a schedule: It is difficult to determine the exact
instructions of a transaction and how these instructions of various transactions interact. For this
reason, the only significant instructions that we will consider further are read and write
instructions, as shown in Table 7. 18
Table 7. 18: Schedule 1- showing only read and write instructions

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

Types of Serializability: The serializability of schedules is of two types:

(a) Conflict Serializability
(b) View Serializability

7.5.1 Conflict Serializability

Let us consider a schedule S in which there are two consecutive instructions I i 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 of Ii and Ij does not matter.

2. Ii = read(Q), Ij = write(Q).
If Ii occurs before Ij, then Ti does not read the value of Q that is written by Tj in instruction Ij. If Ij
occurs before 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 for reasons similar to case-2.

4. Ii = write(Q), Ij = write(Q).
Since both 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 of 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 write(Q) instruction after Ii and Ij in S, then the order of Ii and Ij directly affects the
final value of Q in the database state that results from schedule S.
Non-conflict instructions: When both Ii and Ij are read instructions, then the relative order of
their execution does not matter.
Conflict instructions: We say that Ii and Ij conflict if these are instructions of different
transactions on the same data item, and at least one of these instructions is a write
operation.Table 7. 19 shows the conflicting and non-conflicting instructions in two transactions T1
and T2.
Table 7. 19: Conflicting and non-conflicting instructions in two transactions T1 and T2

The write(A) instruction of T1 in schedule 1 (Table 7. 19) conflicts with the read(A) instruction of
T2. The write(A) instruction of T2 of schedule 1 (Table 7. 19) does not conflict with the read(B)
instruction of T1 because it is on different data items so we can swap these instructions to
generate an equivalent schedule, schedule 2 as shown in Table 7. 20. Regardless of the initial
system state, schedules 1 and 2 both produce the same final system state.

Table 7. 20: schedule 2 after swapping of a pair of instructions in schedule 1

We continue to swap non-conflicting instructions as shown in Figure 7. 7:

 Swap the read(B) instruction of T1 with the write(A) instruction of T2.
 Swap the read(B) instruction of T1 with the read(A) instruction of T2.
 Swap the write(B) instruction of T1 with the write(A) instruction of T2.
  Swap the write(B) instruction of T1 with the read(A) instruction of T2.

Figure 7. 7: Sequence of swapping of non-conflicting instructions

The final result of these swaps, schedule 3 shown in Table 7. 21, is a serial schedule. Thus, we
have shown that schedule 1 is equivalent to a serial schedule. This equivalence implies that,
regardless of the initial system state, schedule 3 will produce the same final state as some serial
schedule will.

If a schedule S 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.

The concept of conflict equivalence leads to the concept of conflict serializability. We say that a
schedule S is a conflict serializable if it is conflict equivalent to a serial schedule. Thus,
schedule 1 is conflict serializable since it is conflict equivalent to the serial schedule, as shown
in Table 7. 21.

Table 7. 21: Schedule 3 a serial schedule that is equivalent to schedule 1

Finally, consider schedule 4 ofTable 7. 22; it consists of only the significant operations (that is, the
read and write) of transactions T3 and T4. This schedule is not conflict serializable since it is not
equivalent to either the serial schedule <T3, T4> or the serial schedule <T4, T3>.
Table 7. 22: Schedule 4

7.5.2 View Serializability

Consider two schedules, S and S’, where the same set of transactions participates in both
schedules. The schedules S and S are said to be view equivalent if three conditions are met:
1. For each data item Q, if transaction Tireads the initial value of Q in schedule S, then
transaction Ti must, in schedule S’, also read the initial value of Q.
2. For each data item Q, if transaction Tiexecutes 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 Timust, in schedule S’, 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 S’.
Conditions 1 and 2 ensure that each transaction reads the same values in both schedules and,
therefore, performs the same operation. Condition 3, coupled with conditions 1 and 2, and
ensures that both schedules result in the same final system state.
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.
 Figure 7. 8: Examples of view equivalence

In the example shown in Figure 7. 8, schedule 3 is not view equivalent to schedule 5, since, in
schedule 3, the value of account A read by transaction T 2 was produced by T1, whereas this case
does not hold in schedule 5.
However, schedule 3 is view equivalent to schedule 6 because:
 In both schedules 3 and 6, T1 reads the initial value of A and B.
 The values of accounts A and B read by transaction T 2 was produced by T1 in both
schedules.
 The final values of accounts A and B are written by T2 in both schedules 3 and 6.

Let us take one more example, as shown in Figure 7. 9, to show a view serializable schedule. We
can see that schedule 7 is view equivalent to serial schedule 8. Thus schedule 7 is view
serializable schedule.

Figure 7. 9: View serializable schedule

Blind writes: Observe that, in schedule 8, transactions T4 and T6 perform 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.
7.6 Testing for Serializability

When designing concurrency control schemes, we must show that schedules generated by the
scheme are serializable. We will now present a simple and efficient method for determining the
conflict serializability of a schedule. Consider a schedule S. We construct a directed graph,
called a precedence graph, from S.

Precedence Graph Method: Conflict serializability of a concurrent schedule can be tested using
the precedence graph method. 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 the transactions participating
in the schedule. The set of edges consists of all edges T i → Tj for which one of three conditions
holds (shown in Figure 7. 10):

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).

Figure 7. 10: Conditions to include an edge in the precedence graph

If the precedence graph for S has a cycle, then schedule S is not conflict serializable. If the
graph contains no cycles, then schedule S is conflict serializable.

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. There are,
in general, several possible linear orders that can be obtained through topological sorting, as
shown inFigure 7. 11.
 Figure 7. 11: Illustration of topological sorting

shows the precedence graphs for schedules 3 and 5 that do not contain cycles. The
Figure 7. 12
precedence graph for schedule 9, on the other hand, contains a cycle, indicating that this
schedule is not conflict serializable.
 Schedule Precedence Graph Explanation Serializability check

read(A) The precedence graph

It contains the
write(A) for Schedule-3
single edge T1 → T2,
contains no cycle
read(B) since all the
write(B) instructions of T1
are executed before
read(A) the first instruction
write(A) of T2 is executed. It is a conflict
read(B) serializable
write(B) schedule.
Schedule-3

read(A) The precedence graph

It contains the
write(A) single edge T2 → T1, for Schedule-5
read(B) since all the contains no cycle
write(B) instructions of T2
read(A) are executed before
the first instruction
write(A) It is a conflict
of T1 is executed.
read(B) serializable
write(B) schedule.
Schedule-5
It contains the edge
read(A) T1 → T2, because T1 The precedence graph
read(A) executes read(A) for Schedule-9 has a
before T2 executes cycle
write(A)
write(A).
read(B) It also contains the
write(A) edge T2 → T1,
read(B) because T2 executes It is not a conflict
write(B) read(B) before T1 serializable
write(B) executes write(B). schedule.
Schedule-9
Figure 7. 12: Precedence graph of a schedule with testing for serializability

Topological Sorting: It is a special method to arrange the elements of a Directed Acyclic Graph
(DAG). It is used to design the scheduling applications where one job needs to be done before
the other.

Algorithm:
1. Indegree of each node is calculated
 2. All the nodes with indegree=0 are put in queue(Q)
3. While (Q is not empty)
Front node of the queue(Q) is removed (N) and the following steps are repeated
for each neighbour node M of node N
Indegree of M is reduced by 1
If indegree=0, then ass M to the rear of the Q
4. Output from queue has the topological ordering of the elements.

Step 1: Indegree of transactions (nodes) are Step 3: Indegree of neighbor nodes of T3, i.e., T2 is
calculated, and node with 0 indegree (T1) is processed reduced by 1 and node with 0 indegree (T2) is
processed.

Step 2: Indegree of neighbor nodes of T1, i.e., T2 and

T3 is reduced by 1 and node with 0 indegree (T3) is Final Step: Sequence of processed transactions-
processed. Topological sorted order is: T1, T3, T2

Figure 7. 13: Illustration of topological sorting algorithm

Example 1: Consider the following schedule for Transactions T1, T2& T3

 Which one of the schedules below is the correct serialization of the above?
(A) T1 T3 T2 (B) T2 T1 T3(C) T2 T3 T1 (D) T3 T1 T2
Solution:
Precedence Graph:

For data item X:

1. T1 reads (X) before T2 writes (X), so there will be an edge from T1 to T2.
2. T1 reads (X) before T3 writes (X); so there will be an edge from T1 to T3.
3. T1 writes (X) before T2 reads(X) and writes (X); so there will be an edge from T 1 to
T2.(edge covered in 1)
4. T3 writes (X) before T2 reads(X) and writes (X); so there will be an edge from T3 to T2.
For data item Y:
5. T3 reads (Y) before T2 writes (Y); so there will be an edge from T3 to T2. (edge covered in
4)

Equivalent serial schedule: T1 T3 T2

Example 2: Which of the following schedules is conflict serializable? For each serializable
schedule, determine the equivalent serial schedule.
a. r1 (X); r3 (X); w1 (X); r2 (X); w3 (X)
b. r1 (X); r3 (X); w3 (X); w1 (X); r2 (X)
 c. r3 (X); r2 (X); w3 (X); r1 (X); w1 (X)

Solution:

a. r1 (X); r3 (X); w1 (X); r2 (X); w3 (X)

Precedence Graph:-

1. T1 reads (X) before T3 writes (X); so there will be an edge from T1 to T3.
2. T3 reads (X) before T1 writes (X); so there will be an edge from T3 to T1.
3. T1 writes (X) before T2 reads (X); so there will be an edge from T1 to T2.
4. T2 reads (X) before T3 writes (X); so there will be an edge from T2 to T3.
5. T1 writes (X) before T3 writes (X); so there will be an edge from T1 to T3. (edge covered
already in 1)

In the above precedence graph, there are two cycles, i.e., T 1 T2 T3 T1 and T1 T3 T1.
Therefore, the schedule is not conflict-serializable.

b. r1 (X); r3 (X); w3 (X); w1 (X); r2 (X)

Precedence Graph:-

1. T1 reads (X) before T3 writes (X); so there will be an edge from T1 to T3.
2. T3 reads (X) before T1 writes (X); so there will be an edge from T3 to T1.
 3. T3 writes (X) before T1 writes (X); so there will be an edge from T3 to T1. (edge covered
already in 2)
4. T3 writes (X) before T2 reads (X); so there will be an edge from T3 to T2.
5. T1 writes (X) before T2 reads (X); so there will be an edge from T1 to T2.

In the above precedence graph, there is a cycle T1 T3 T1. Therefore, the schedule is not
conflict-serializable.

c. r3 (X); r2 (X); w3 (X); r1 (X); w1 (X)

Precedence Graph:-

1. T3 reads (X) before T1 writes (X); so there will be an edge from T3 to T1.
2. T2 reads (X) before T3 writes (X); so there will be an edge from T2 to T3.
3. T2 reads (X) before T1 writes (X); so there will be an edge from T2 to T1.
4. T3 writes (X) before T1 reads (X); so there will be an edge from T3 to T1. (edge covered
already in 1)
5. T3 writes (X) before T1 writes (X); so there will be an edge from T3 to T1. (edge covered
already in 1)

In the above precedence graph, there are no cycles. Therefore, the schedule is conflict-
serializable.
The equivalent serial schedule is T2, T3, T1.

7.7 Recoverability
As we already know that transactions may not execute successfully due to hardware failure,
system crash, or any software issue. We need some recovery procedure when the system
restarts. In this section, we are dealing with the recovery of failed transactions in two broad
areas.
1. When a transaction fails after entering into partially committed state.
2. Where dependent transactions may lead to a situation where recovery is not possible.
1. Failure during partially committed state: If a transaction fails after entering into the
partially committed state and values are either reflected or not reflected on stable storage.
This could be done by Implementing Atomicity and durability properties. The DBMS
component that ensures atomicity and durability is called the recovery manager.

Methods or Recovery techniques:

 Shadow copy
 Log-based recovery
Let’s discuss each of them in detail:

a. Shadow copy: In this scheme, if any transaction wants to update the data itemsassuming
only one transaction is active at a time, then:
a. It first creates the copy of the entire database as a new copy and an old copy
named as shadow copy
b. All changes were made in the new copy leaving the shadow copy untouched.
c. If at any point during execution, the transaction is aborted, then the system
deletes the new copy and the old copy remains unaffected.
d. A pointer called DB-pointer is maintained on disk; it points to the current copy of
the database. Figure 7. 14 below depicts the scheme, showing the database state
before and after the update.

Figure 7. 14: Technique to ensure atomicity & durability using Shadow copy scheme

e. After the operating system has written all the pages to disk, the database system
updates the pointer DB-pointer to point to the new copy of the database; the
new copy then becomes the current copy of the database. The old copy is then
deleted.
 f. Suppose the system fails at any time before the updated DB-pointer is written to
disk. Then, when the system restarts, it will read DB-pointer and will thus see the
original contents of the database.

Remember: The implementation actually depends on the write to db-pointer being atomic; that
is, either all its bytes are written, or none of its bytes are written.

If some of the bytes of the pointer were updated by the write, but others were not, the pointer
is meaningless, and neither old nor new versions of the database may be found when the
system restarts

Thus, the atomicity and durability properties of transactions are ensured by the shadow-copy
implementation of the recovery-management component.

Note: Unfortunately, this implementation is extremely inefficient in the context of

largedatabases, since executing a single transaction requires copying the entire
database.Furthermore, the implementation does not allow transactions to execute
concurrentlywith one another. There are practical ways of implementing atomicity and
durabilitythat are much less expensive and more powerful, as discussed next.

b. Log-based recovery: A DBMS ensures transaction atomicity by undoing the actions of

incomplete transactions. This means that users can ignore incomplete transactions in
thinking about how the database is modified by transactions over time. To do this, the
DBMS maintains a record called the log of all writes to the database. The log is also used to
ensure durability: If the system crashes before the changes made by a completed
transaction are written to disk, the log is used to remember and restore these changes
when the system restarts. These ways come under Recovery techniques and will be
discussed in detail in the next chapter.
2. Transactions dependency on each other: In some cases, it is not even possible to recover
correctly after a failure. There are multiple transactions dependent on each other for
common data items. Execution of a few instructions may lead to a situation where recovery
is not possible. Let us understand this with an example shown in Table 7. 23 below:

“To generate the cumulative attendance summary of a particular section Q in which multiple
subject faculty are taking the classes in a day. All faculties will add the count of his/her class
in Q data item (Representing the section Q) only"

Now consider a situation where Faculty1 updated the count in data item Q about his/her class
count but forgot to make his/her action permanent using commit. After faculty 1, faculty2
updated his count of attendees in Q and permanently updated his action doing commit at the
end. Now, after some time transaction of Faculty1, i.e., T1 gets failed due to any reason.
Because changes are not permanent, hence rollback occurs, but Q is 75 in the database
(committed by faculty2). Such types of schedules are irrecoverable, resulting in incorrect data.
Table 7. 23: Irrecoverable schedule

Timestamp T1 T2 Remarks Before Execution Q=20

1 read(Q); F1 faculty readds Q=20
2 Q=Q+30; F1 faculty added his class count Q=20+30
3 write(Q); Now updated Q=50
4 read(Q); at timestamp 4, F2 faculty reads the uncommitted value Q as 50
5 Q=Q+35; Q is modfied to 75
6 write(Q); Q=75 updated on Stale storage/Disk
7 commit ; Faculty 2 committed his execution.
8 Fail Due to any reason Faculty1 action's fails. Uncommitted -->rollback & restart later
After Execution Q=75 which is incorrect

Hence, it is important to design recoverable schedules. To achieve this, we need to place

restrictions on the type of schedules permitted in the system. The type of schedules acceptable
from the viewpoint of recovery from transaction failure is:
 Recoverable schedule
 Cascadeless schedule
 Strict schedule

Let’s discuss them in detail:

a. Recoverable schedule: 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, and the commit operation
of Ti appears before the commit operation of Tj.
Table 7. 24 shows an example of a recoverable schedule where T2 reads the data item written
by T1 and the commit of T1 appears before the commit operation of T2 transactions. Hence,
T2 reads the committed value of Q. If later T1 fails due to any reason, then no need to
rollback the dependent transaction T2.
Table 7. 24: Recoverable schedule

Timestamp T1 T2 Remarks Before Execution Q=20

1 read(Q); F1 faculty readds Q=20
2 Q=Q+30; F1 faculty added his class count Q=20+30
3 write(Q); Q=50 updated on Stale storage/Disk
4 commit ; Faculty1 committed the Q
5 read(Q); Faculty2 reads committed value of Q using read(Q) as 50
6 Q=Q+35; Q is modfied to 75
7 write(Q); Q=75 updated on Stale storage/Disk
8 Fail Due to any reason Faculty1 action's fails. No impact on T2
After Execution Q=75 which is correct and recoverable
Note: 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, as illustrated in Table 7. 25.

Table 7. 25: Cascading schedule

T5 T6 T7
read(A);
read(B);
write(A);
read(A);
write(A);
read(A);

Explanation: Transaction T5 writes a value of A that is read by transaction T6. Transaction T6

writes a value of A that is read by transaction T7. Suppose that, at this point, T5 fails. T5 must
be rolled back. Since T6 is dependent on T5, T6 must be rolled back. Since T7 is dependent on
T6, T7 must be rolled back. This phenomenon, in which a single transaction failure leads to a
series of transaction rollbacks, is called cascading rollback.
Cascading rollback is undesirable since it leads to the undoing of a significant amount of work. It
is desirable to restrict the schedules to those where cascading rollbacks cannot occur. Such
schedules are called cascadeless schedules. Therefore, we must design the cascadeless
schedule.
b. Cascadeless schedule: 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 as shown in Figure 7. 15. It is easy to verify that every
cascadeless schedule is also recoverable.

Figure 7. 15: Examples of cascadeless schedule

c. Strict schedule: If in a schedule, a transaction is neither allowed to read nor write a data
item until the last transaction that has been written it is committed or aborted and then
such a schedule is called a Strict Schedule, an example is shown in Table 7. 26.

In other words,

 The strict schedule allows only committed read and write operations.
 A strict schedule implements more restrictions than a cascadeless schedule.

Table 7. 26: Strict schedule

T8 T9
write(A);
commit/rollback;
read(A)/write(B);

Note: Strict schedules are stricter than cascadeless schedules. Every strict schedule is a
cascadeless schedule, but vice versa is not true. For easy understanding, looks Figure 7. 16:

Figure 7. 16: Summary of types of schedules

Problem 1: For the given schedule, which schedule is recoverable?

S1: r1(X), w1(X), r2(X), r1(Y), r2(Y), w2(X), w1(Y), c1, c2;
S2: r1(X), r2(X), r1(Z), r3(X), r3(Y), w1(X),w3(Y), r2(Y), w2(Z), w2(Y), c1, c2, c3;

Solution: As we already know that:

 ri(X) = the transaction Ti reads the DB element X

 wi(X) = the transaction Ti writes the DB element X

Hint: A schedule is recoverable if there is no dirty read at all. But if dirty read exists and
commits operations appear in order of dirty read, then schedules are recoverable. Otherwise,
schedules are irrecoverable.
Considering S1, for a schedule to be T1 must commit before commit of T2. Plotting of
dependency and order of commit:

2
1
Here, r1(X), w1(X), r2(X), r1(Y), r2(Y), w2(X), w1(Y), c1, c2;

T1 T2 T1 T2

 At this point 1: dirty read is performed by T2. Now dependency is created, T2 is dependent
on T1. Now we will check whether the order of commit is in order of dependency.
 At point 2: Yes, the order of commit is the same as the order of dependency. Now the
issue related to dirty read is resolved as the commit operation of T1 appears before the
commit operations of T2; hence this schedule becomes recoverable.
Considering S2 schedule now, Plotting of dependency and order of commit:

2
1

Here, r1(X), r2(X), r1(Z), r3(X), r3(Y), w1(X),w3(Y), r2(Y), w2(Z), w2(Y), c1, c2, c3;

T3 T2 T2 T3

At point 1: Here, Dirty read exists, i.e., T2 is dependent on T3. This schedule will be recoverable
only if the commit order is also same as dependency.
At point 2:But commit operation of T3 appears after commit operation of T2. Therefore, the
order of commit is different from the order of dependency. Hence schedule is not recoverable.

Problem 2: Is the given schedule cascadeless or not?

S1: r1(A),w2(A),r1(B),c1,w3(B), r3(B),w3(A),c3,r2(C),c2;
S2: r1(A),w2(B),c2,r1(B),w1(B),c1;
Solution:
Hint: A schedule is cascadeless if there is no dirty read or dependent transaction reads the
committed value only.
Consider S1: r1(A),w2(A),r1(B),c1,w3(B), r3(B),w3(A),c3,r2(C),c2; as there is no dirty read
hence schedule is cascadeless.
 1

Consider S2: r1(A),w2(B),c2,r1(B),w1(B),c1;

 At point 1, T1 is reading the value of data item B, which is written by T2, i.e., T1 is
dependent on T2. Then we need to analyze whether this read is a dirty read or not?
 At point 2, it is clearly visible that T2 commits immediately after w2(B), and after that, T1
reads the committed value of T2; hence this read is not dirty read. Therefore, the schedule
is cascadeless.

7.8 Transaction Control using SQL

A transaction is a logical unit of work that contains one or more SQL statements. A transaction
begins with an executable SQL statement and ends when it is committed or rolled back, either
explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.
The effects of all the SQL statements in a transaction can be all committed (applied to the
database), or all rolled back (undone from the database).
To illustrate the concept of a transaction, consider a university admission process where a
student's parent transfers an amount for the student fee to the university. The transaction can
consist of three separate operations:

 Decrement the account of the parent

 Increment the account of university
 Record the transaction in the transaction journal

An RDBMS must allow any one of two situations. If all three SQL statements can be performed
to maintain the accounts in proper balance, the effects of the transaction can be applied to the
database. However, if a problem such as insufficient funds, an invalid account number, or a
hardware failure prevents one or two of the statements in the transaction from completing, the
entire transaction must be rolled back so that the balance of all accounts is correct.
 Transaction Begins

UPDATE paccount Decrement Parent’s account

SET balance=balance-5000
WHERE pacno=101;

UPDATE uaccount Increment University’s account

SET balance=balance+5000
WHERE uacno=1001;

INSERT INTO journal (fromac, toac, amount) Record in transaction journal

VALUES(101,1001,5000);

COMMIT; End Transaction

Transaction Ends

Figure 7. 17: Transaction Control

Here paccount is the table having parent’s account details like parents account number (pacno)
and balance, uaccount is the table having university account details like a university account
number (uacno) and balance, the journal is the table to store the payment transfer information
like from which parent’s account number amount is received (fromac), to which university
account number the amount to be deposited (toac) and how much fee amount is received.
Before trying to execute the above statements, you need to create a database, required tables,
and some sample records. You can use the following SQL statements to create a demo
database, tables, and records.

CREATEDATABASE university;
CREATETABLE paccount
(pacno INTPRIMARYKEY, pname VARCHAR(50)NOT NULL, balance FLOATDEFAULT 0);
CREATETABLE uaccount
(uacno INTPRIMARYKEY, uname VARCHAR(50)NOT NULL, balance FLOATDEFAULT 0);
CREATETABLE journal
(tid INTPRIMARYKEYIDENTITY, fromac INTNOT NULL, toac INTNOT NULL, amount FLOATNOT
NULL);

INSERTINTO paccount VALUES(101,'Rakesh Kumar',12000);

INSERTINTO uaccount VALUES(1001,'AKTU',20000);

SELECT*FROM paccount;
SELECT*FROM uaccount;
Output:
 pacno pname balance
101 Rakesh Kumar 12000

uacno uname balance

1001 AKTU 20000

Transaction control is the management of changes made by DML statements and the grouping
of DML statements into transactions.
In general, application designers are concerned with transaction control so that work is
accomplished in logical units and data is kept consistent.
Table 7. 27 illustrates the basic concepts of transaction control.

Table 7. 27: Transaction control statements

Timestamp Session Remark

1 BEGIN TRANSACTION This statement begins a transaction
2 UPDATE paccount This statement updates the the balance in parent's
SET balance=balance-5000 account
WHERE pacno=101;

3 UPDATE uaccount This statement updates the the balance in

SET balance=balance+5000 university's account
WHERE uacno=1001;

4 INSERT INTO journal This statements insert the record of payment

(fromac, toac, amount) transfer
VALUES(101,1001,5000);

This statement commits all changes made in

5 COMMIT; transaction then ends the transaction.

If you execute the above statements, you will get the following output

BEGINTRANSACTION
UPDATE paccount SET balance=balance-5000 WHERE pacno=101;
UPDATE uaccount SET balance=balance+5000 WHERE uacno=1001;
INSERTINTO journal(fromac, toac, amount) VALUES(101,1001,5000);
COMMIT;

SELECT*FROM paccount;
SELECT*FROM uaccount;
SELECT*FROM journal;

Output:
 pacno pname balance
101 Rakesh Kumar 7000

uacno uname balance

1001 AKTU 25000

tid fromac toac amount

1 101 1001 5000