UNIT – 4

INTRODUCTION TO TRANSACTION PROCESSING CONCEPTS &

THEORY
Introduction to Transaction Processing
A transaction in database is a logical unit of work that must succeed or fail in its entirely. That means, a
transaction may involve number of sub-steps, which should either all be carried out successfully or all be
ignored if any failure occurs.
Hence, a transaction in DBMS is an atomic process that is either performed into completion entirely or is
not performed at all.
 Generally, the operations performed in a transaction include one or more of database operations
like insert, delete, update or retrieve data.
 A transaction involving only data retrieval without any data update is called read-only transaction.
Each high-level operation can be divided into a number of low-level tasks or operations. For example, a
data update operation can be divided into three tasks −
 read_item () − reads data item from storage to main memory.

 modify_item () − change value of item in the main memory.

 write_item () − write the modified value from main memory to storage.

Operations of Transaction
A user can make different types of requests to access and modify the contents of a database. So, we
have different types of operations relating to a transaction. They are discussed as follows.
i) Read(X)
A read operation is used to read the value of X from the database and store it in a buffer in the main
memory for further actions such as displaying that value. Such an operation is performed when a user
wishes just to see any content of the database and not make any changes to it. For example, when a
user wants to check his/her account’s balance, a read operation would be performed on user’s account
balance from the database.
ii) Write(X)
A write operation is used to write the value to the database from the buffer in the main memory. For a
write operation to be performed, first a read operation is performed to bring its value in buffer, and then
some changes are made to it according to the user’s request, then to store the modified value back in
the database, a write operation is performed. For example, when a user requests to withdraw some
money from his account, his account balance is fetched from the database using a read operation, then
the amount to be deducted from the account is subtracted from this value, and then the obtained value is
stored back in the database using a write operation.
iii) Commit
This operation in transactions is used to maintain integrity in the database. To ensure that further
operations of any other transaction are performed only after work of the current transaction is done, a
commit operation is performed to the changes made by a transaction permanently to the database.
iv) Rollback
This operation is performed to bring the database to the last saved state when any transaction is
interrupted in between due to any power, hardware, or software failure. In simple words, it can be said
that a rollback operation does undo the operations of transactions that were performed before its
interruption to achieve a safe state of the database and avoid any kind of ambiguity or inconsistency.

Transaction and System Concepts

1. Transaction States / States of a database transaction
Although a transaction is an atomic unit of work, it passes through various states during its lifetime.
The state of a transaction is defined by the current activity it is performing. Let’s consider the
following diagram.

Active:
It is the first stage of any transaction when it has begun to execute. Operations such as insertion,
deletion, or updation are performed during this state. During this state, the data records are under
manipulation and they are not saved to the database, rather they remain somewhere in a buffer in
the main memory.
Partially Committed:
This state of transaction is achieved when it has completed most of the operations and is executing its
final operation (result yet to come). It can be a signal to the commit operation. If some kind of error
occurs during this state, the transaction goes into a failed state, else it goes into the Committed state.
Committed:
This state of transaction is achieved when all the transaction-related operations have been executed
successfully along with the Commit operation, i.e. data is saved into the database after the required
manipulations in this state. This marks the successful completion of a transaction.
Failed:
If any of the transaction-related operations cause an error during the active or partially committed
state, further execution of the transaction is stopped and it is brought into a failed state. Here, the
database recovery system makes sure that the database is in a consistent state. A failed transaction
can no longer proceed further.
Aborted:
If the error is not resolved in the failed state, then the transaction is aborted and a rollback operation
is performed to bring database to the last saved consistent state. When the transaction is aborted, the
database recovery module either restarts the transaction or kills it.
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 sequential, append-
only file that is kept on disk, so it is not affected by any type of failure except for disk or catastrophic
failure.
3. Commit Point of a Transaction
A transaction reaches its commit point when all its operations that access the database have been
executed successfully and the effect of all the transaction operations on the database have been
recorded in the log. Beyond the commit point, the transaction is said to be committed, and its effect
must be permanently recorded in the database. The transaction then writes a commit record into the
log.

Properties of Transactions
In order to maintain consistency in a database, before and after the transaction, certain properties are
followed. These are called ACID properties.

Atomicity:
This property ensures that either the entire transaction takes place at once or doesn’t happen at all.
There is no midway i.e. transactions do not occur partially. It involves the following two operations.
Abort: If a transaction aborts, changes made to the database are not visible.
Commit: If a transaction commits, changes made are visible.
Consistency:
This means that integrity constraints must be maintained so that the database is consistent before
and after the transaction. It refers to the correctness of a database.
Isolation:
This property ensures that multiple transactions can occur concurrently without leading to the
inconsistency of the database state. Transactions occur independently without interference. Changes
occurring in a particular transaction will not be visible to any other transaction until that particular
change in that transaction is written to memory or has been committed.
Durability:
This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a system
failure occurs. These updates now become permanent and are stored in non-volatile memory.

Schedule
A series of operation from one transaction to another transaction is known as schedule. It is used
to preserve the order of the operation in each of the individual transaction.

1. Serial Schedule
The serial schedule is a type of schedule where one transaction is executed completely before
starting another transaction. In the serial schedule, when the first transaction completes its cycle,
then the next transaction is executed.
For example: Suppose there are two transactions T1 and T2 which have some operations. If it has
no interleaving of operations, then there are the following two possible outcomes:
1. Execute all the operations of T1 which was followed by all the operations of T2.

2. Execute all the operations of T2 which was followed by all the operations of T1.

In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2. And in the
given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.

2. Non-serial Schedule
If interleaving of operations is allowed, then there will be non-serial schedule. It contains many
possible orders in which the system can execute the individual operations of the transactions.
In the following figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It has
interleaving of operations.
3.Serializable schedule
The serializability of schedules is used to find non-serial schedules that allow the transaction to
execute concurrently without interfering with one another. It identifies which schedules are correct
when executions of the transaction have interleaving of their operations.
A non-serial schedule will be serializable if its result is equal to the result of its transactions
executed serially.

Serializability in DBMS
Serializability is a term that is a property of the system that describes how the different process
operates the shared data. If the result given by the system is similar to the operation performed by
the system, then in this situation, we call that system serializable. Here the cooperation of the
system means there is no overlapping in the execution of the data.
Serializability ensures that the final result is equivalent to the sequential operation of the data.
Serializability can be achieved through Serializable Schedule

Types of Serializability
1. Conflict Serializability
A database management system (DBMS) schedule’s ability to prevent the sequence of
conflicting transactions from having an impact on the transactions’ results is known as conflict
serializability in DBMS. Conflicting transactions are those that make unauthorized changes to
the same database data item.
Conflict serializability maintains the consistency of the database.
There is some condition for the conflict serializability of the database. These are as below.
o Both operations should have different transactions.
o Both transactions should have the same data item.
o There should be at least one write operation between the two operations.

Example
Transaction 1 Transaction 2 Transaction 3
 R(x)
R(y)
R(x)
R(y)
R(z)
W(y)
W(z)
R(z)
W(x)
W(z)

2. View Serializability
View serializability is a type of operation in the serializable in which each transaction should
produce some result and these results are the output of proper sequential execution of the data
item. Unlike conflict serialized, the view serializability focuses on preventing inconsistency in the
database.
View Serializability is the process of determining whether or not a given schedule is view
serializable.
Example
Transaction 1 Transaction 2
R(a)
W(a)
R(a)
W(a)
R(b)
W(b)
R(b)
W(b)

Let’s swap the read-write operations in the middle of the two transactions to create the view
equivalent schedule.
Transaction 1 Transaction 2
R(a)
W(a)
R(b)
W(b)
R(a)
W(a)
R(b)
W(b)
What is a conflicting pair in transactions?
Two operations inside a schedule are called conflicting if they meet these three conditions:
1. They belong to two different transactions.
2. They are working on the same data piece.
3. One of them is performing the WRITE operation.
To conclude, let’s take two operations on data: "a". The conflicting pairs are:
1. READ(a) - WRITE(a)
 2. WRITE(a) - WRITE(a)
3. WRITE(a) - READ(a)
Note:
There can never be a read-read conflict as there is no change in the data.
Recoverability