Transaction processing concepts for computer science Dep’t

CHAPTER-TWO
Transaction processing concepts
Transaction is a logical unit of work that represents real-world events of any organization or an
enterprise whereas concurrency control is the management of concurrent transaction execution. 
Transaction processing systems execute database transactions with large databases and hundreds
of concurrent users, for example, railway and air reservations systems, banking system, credit
card processing, stock market monitoring, super market inventory and checkouts and so on.
TRANSACTION :
A transaction is a logical unit of work of database processing that includes one or more database
access operations.
A transaction can be defined as an action or series of actions that is carried out by a single user or
application program to perform operations for accessing the contents of the database. The
operations can include retrieval, (Read), insertion (Write), deletion and modification.  A
transaction must be either completed or aborted. 
It can either be embedded within an application program or can be specified interactively via a
high-level query language such as SQL.  Its execution preserves the consistency of the database.
Each transaction should access shared data without interfering with the other transactions and
whenever a transaction successfully completes its execution; its effect should be permanent.

A transaction is a sequence of READ and WRITE actions that are grouped together to from a
database access. A transaction may consist of a simple SELECT operation to generate a list of
table contents, or it may consist of a series of related UPDATE command sequences.
A transaction can include the following basic database access operations:
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.

Commit To save the work done permanently.

Rollback To undo the work done.

Transaction that changes the contents of the database must alter the database from
one consistent state to another. A consistent database state is one in which all data integrity
constraints are satisfied.

Prepared by addisu s. Page 1

 Transaction processing concepts for computer science Dep’t

To ensure database consistency, every transaction must begin with the database in a known
consistent state.

Transaction Execution and Problems:

A transaction which successfully completes its execution is said to have been committed. Otherwise, the
transaction is aborted.
Thus, if a committed transaction performs any update operation on the database, its effect must be reflected
on the database even if there is a failure.

A transaction can be in one of the following states:

 
State Description

Active  A transaction goes into an active state immediately after it starts execution, where it can issue READ
state and WRITE operations.
A transaction may be aborted when the transaction itself detects an error during execution which it
cannot recover from, for example, a transaction trying to debit loan amount of an employee from his
insufficient gross salary. A transaction may also be aborted before it has been committed due to
system failure or any other circumstances beyond its control.

Partially When the transaction ends, it moves to the partially committed state.When the last state is reached.
committed To this point, some recovery protocols need to ensure that a system failure will not result in an
inability to record the changes of the transaction permanently. Once this check is successful, the
transaction is said to have reached its commit point and enters the committed state. 

Aborted When the normal execution can no longer be performed.

Failed or aborted transactions may be restarted later, either automatically or after being resubmitted
by the user as new transactions.

Committed After successful completion of transaction.

A transaction is said to be in a committed state if it has partially committed and it can be ensured that
it will never be aborted. 

Prepared by addisu s. Page 2

 Transaction processing concepts for computer science Dep’t

Transaction Properties:

Atomicity 
By this, we mean 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. Each transaction is considered as
one unit and either runs to completion or is not executed at all. It involves the following two
operations. 
—Abort: If a transaction aborts, changes made to database are not visible. 
—Commit: If a transaction commits, changes made are visible. 
Atomicity is also known as the ‘All or nothing rule’. 
  Consider the following transaction T consisting of T1 and T2: Transfer of 100 from
account X to account Y. 

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. 

Prepared by addisu s. Page 3

 Transaction processing concepts for computer science Dep’t

The atomicity property of a transaction requires that all operations of a transaction be completed,
if not, the transaction is aborted. In other words, a transaction is treated as single, individual
logical unit of work. 
Therefore, a transaction must execute and complete each operation in its logic before it commits
its changes. As stated earlier, the transaction is considered as one operation even though there are
multiple read and writes.  Thus, transaction completes or fails as one unit.
The atomicity property of transaction is ensured by the transaction recovery subsystem of a
DBMS.
In the event of a system crash in the midst of transaction execution, the recovery techniques undo
any effects of the transaction on the database.
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. Referring to the
example above, 
The total amount before and after the transaction must be maintained. 
Total before T occurs = 500 + 200 = 700. 
Total after T occurs = 400 + 300 = 700. 
Therefore, database is consistent. Inconsistency occurs in case T1 completes but T2 fails. As a
result T is incomplete. 
Database consistency is the property that every transaction sees a consistent database instance. In
other words, execution of a transaction must leave a database in either its prior stable state or a
new stable state that reflects the new modifications (updates) made by the transaction.
If the transaction fails, the database must be returned to the state it was in prior to the execution
of the failed transaction. 
If the transaction commits, the database must reflect the new changes.Thus, all resources are
always in a consistent state.
The preservation of consistency is generally the responsibility of the programmers who write the
database programs or of the DBMS module that enforces integrity constraints. 
A database program should be written in a way that guarantees that, if the database is in a
consistent state before executing the transaction, it will be in a consistent state after the complete
execution of the transaction, assuming that no interference with other transactions occur.
In other words, a transaction must transform the database from one consistent state to another
consistent state.
Isolation 
This property ensures that multiple transactions can occur concurrently without leading to the
inconsistency of 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. This
property ensures that the execution of transactions concurrently will result in a state that is
equivalent to a state achieved these were executed serially in some order. 
Let X= 500, Y = 500. 
Consider two transactions T and T”. 
 

Prepared by addisu s. Page 4

 Transaction processing concepts for computer science Dep’t

Suppose T has been executed till Read (Y) and then T’’ starts. As a result , interleaving of

operations takes place due to which T’’ reads correct value of X but incorrect value of Y and
sum computed by 
T’’: (X+Y = 50, 000+500=50, 500) 
is thus not consistent with the sum at end of transaction: 
T: (X+Y = 50, 000 + 450 = 50, 450). 
This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take
place in isolation and changes should be visible only after they have been made to the main
memory. 
 Isolation property of a transaction means that the data used during the execution of a transaction
cannot be used by a second transaction until the first one is completed. This property isolates
transactions from one another.In other words, if a transaction T1 is being executed and is using
the data item X, that data item cannot be accessed by any other transaction (T2………..Tn) until
T1 ends. 
The isolation property is enforced by the concurrency control subsystem of the DBMS.
  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.
The effects of the transaction, thus, are never lost. 
The ACID properties, in totality, provide a mechanism to ensure correctness and consistency
of a database in a way such that each transaction is a group of operations that acts a single unit,
produces consistent results, acts in isolation from other operations and updates that it makes
are durably stored. 
The durability property of transaction indicates the performance of the database's consistent
state. It states that the changes made by a transaction are permanent. 
They cannot be lost by either a system failure or by the erroneous operation of a faulty
transaction. When a transaction is completed, the database reaches a consistent state and that
state cannot be lost, even in the event of system's failure.
Durability property is the responsibility of the recovery subsystem of the DBMS.
DBMS Schedules and the Types of Schedules
We know that transactions are set of instructions and these instructions perform operations on
database. When multiple transactions are running concurrently then there needs to be a sequence
in which the operations are performed because at a time only one operation can be performed on
the database. This sequence of operations is known as Schedule.
Lets take an example to understand what is a schedule in DBMS.

Prepared by addisu s. Page 5

 Transaction processing concepts for computer science Dep’t

DBMS Schedule example

The following sequence of operations is a schedule. Here we have two transactions T1 & T2
which are running concurrently.
This schedule determines the exact order of operations that are going to be performed on
database. In this example, all the instructions of transaction T1 are executed before the
instructions of transaction T2, however this is not always necessary and we can have various
types of schedules which we will discuss in this article.

T1 T2
---- ----
R(X)
W(X)
R(Y)
R(Y)
R(X)
W(Y)

Types of Schedules in DBMS

We have various types of schedules in DBMS. Lets discuss them one by one.

Serial Schedule
In Serial schedule, a transaction is executed completely before starting the execution of another
transaction. In other words, you can say that in serial schedule, a transaction does not start
execution until the currently running transaction finished execution. This type of execution of
transaction is also known as non-interleaved execution. The example we have seen above is the
serial schedule.
Lets take another example.
Serial Schedule example
Here R refers to the read operation and W refers to the write operation. In this example, the
transaction T2 does not start execution until the transaction T1 is finished.
T1 T2
---- ----

Prepared by addisu s. Page 6

 Transaction processing concepts for computer science Dep’t

R(A)
R(B)
W(A)
commit
R(B)
R(A)
W(B)
commit
Strict Schedule
In Strict schedule, if the write operation of a transaction precedes a conflicting operation (Read
or Write operation) of another transaction then the commit or abort operation of such transaction
should also precede the conflicting operation of other transaction.
Lets take an example.
Strict Schedule example
Lets say we have two transactions Ta and Tb. The write operation of transaction Ta precedes the
read or write operation of transaction Tb, so the commit or abort operation of transaction Ta
should also precede the read or write of Tb.

Ta Tb
----- -----
R(X)
R(X)
W(X)
commit
W(X)
R(X)
commit
Here the write operation W(X) of Ta precedes the conflicting operation (Read or Write
operation) of Tb so the conflicting operation of Tb had to wait the commit operation of Ta.
Cascadeless Schedule
In Cascadeless Schedule, if a transaction is going to perform read operation on a value, it has to
wait until the transaction who is performing write on that value commits.
Cascadeless Schedule example
For example, lets say we have two transactions Ta and Tb. Tb is going to read the value X after
the W(X) of Ta then Tb has to wait for the commit operation of transaction Ta before it reads the
X.
Ta Tb
----- -----
R(X)
W(X)
W(X)
commit
R(X)
W(X)
commit
Prepared by addisu s. Page 7
 Transaction processing concepts for computer science Dep’t

Recoverable Schedule
In Recoverable schedule, if a transaction is reading a value which has been updated by some
other transaction then this transaction can commit only after the commit of other transaction
which is updating value.
Recoverable Schedule example
Here Tb is performing read operation on X after the Ta has made changes in X using W(X) so
Tb can only commit after the commit operation of Ta.
Ta Tb
----- -----
R(X)
W(X)
R(X)
W(X)
R(X)
commit
commit

DBMS Serializability

When multiple transactions are running concurrently then there is a possibility that the database
may be left in an inconsistent state. Serializability is a concept that helps us to check
which schedules are serializable. A serializable schedule is the one that always leaves the
database in consistent state.

What is a serializable schedule?

A serializable schedule always leaves the database in consistent state. A serial schedule is always
a serializable schedule because in serial schedule, a transaction only starts when the other
transaction finished execution. However a non-serial schedule needs to be checked for
Serializability.
A non-serial schedule of n number of transactions is said to be serializable schedule, if it is
equivalent to the serial schedule of those n transactions. A serial schedule doesn’t allow
concurrency, only one transaction executes at a time and the other starts when the already
running transaction finished.
Types of Serializability
There are two types of Serializability.
1. Conflict Serializability
2. View Serializability
DBMS Conflict Serializability
In the DBMS Schedules guide, we learned that there are two types of schedules – Serial & Non-
Serial. A Serial schedule doesn’t support concurrent execution of transactions while a non-serial
schedule supports concurrency. We also learned in Serializability tutorial that a non-serial
schedule may leave the database in inconsistent state so we need to check these non-serial
schedules for the Serializability.

Prepared by addisu s. Page 8

 Transaction processing concepts for computer science Dep’t

Conflict Serializability is one of the type of Serializability, which can be used to check whether
a non-serial schedule is conflict serializable or not.
What is 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 same data item.
3. At least one of the operation is a write operation.
Lets see some examples to understand this:
Example 1: Operation W(X) of transaction T1 and operation R(X) of transaction T2 are
conflicting operations, because they satisfy all the three conditions mentioned above. They
belong to different transactions, they are working on same data item X, one of the operation in
write operation.
Example 2: Similarly Operations W(X) of T1 and W(X) of T2 are conflicting operations.
Example 3: Operations W(X) of T1 and W(Y) of T2 are non-conflicting operations because both
the write operations are not working on same data item so these operations don’t satisfy the
second condition.
Example 4: Similarly R(X) of T1 and R(X) of T2 are non-conflicting operations because none
of them is write operation.
Example 5: Similarly W(X) of T1 and R(X) of T1 are non-conflicting operations because both
the operations belong to same transaction T1.
Conflict Equivalent Schedules
Two schedules are said to be conflict Equivalent if one schedule can be converted into other
schedule after swapping non-conflicting operations.
Conflict Serializable check
Lets check whether a schedule is conflict serializable or not. If a schedule is conflict Equivalent
to its serial schedule then it is called Conflict Serializable schedule. Lets take few examples of
schedules.
Example of Conflict Serializability
Lets consider this schedule:

T1 T2
----- ------
R(A)
R(B)
R(A)
R(B)
W(B)
W(A)
To convert this schedule into a serial schedule we must have to swap the R(A) operation of
transaction T2 with the W(A) operation of transaction T1. However we cannot swap these two

Prepared by addisu s. Page 9

 Transaction processing concepts for computer science Dep’t

operations because they are conflicting operations, thus we can say that this given schedule
is not Conflict Serializable.
Lets take another example:
T1 T2
----- ------
R(A)
R(A)
R(B)
W(B)
R(B)
W(A)
Lets swap non-conflicting operations:
After swapping R(A) of T1 and R(A) of T2 we get:
T1 T2
----- ------
R(A)
R(A)
R(B)
W(B)
R(B)
W(A)
After swapping R(A) of T1 and R(B) of T2 we get:

T1 T2
----- ------
R(A)
R(B)
R(A)
W(B)
R(B)
W(A)
After swapping R(A) of T1 and W(B) of T2 we get:

T1 T2
----- ------
R(A)
R(B)
W(B)
R(A)
R(B)
W(A)
We finally got a serial schedule after swapping all the non-conflicting operations so we can say
that the given schedule is Conflict Serializable.

Prepared by addisu s. Page 10

 Transaction processing concepts for computer science Dep’t

DBMS View Serializability

What is View Serializability?

View Serializability is a process to find out that a given schedule is view serializable or not.
To check whether a given schedule is view serializable, we need to check whether the given
schedule is View Equivalent to its serial schedule. Lets take an example to understand what I
mean by that.
Given Schedule:
T1 T2
----- ------
R(X)
W(X)
R(X)
W(X)
R(Y)
W(Y)
R(Y)
W(Y)
Serial Schedule of the above given schedule:
As we know that in Serial schedule a transaction only starts when the current running transaction
is finished. So the serial schedule of the above given schedule would look like this:

T1 T2
----- ------
R(X)
W(X)
R(Y)
W(Y)
R(X)
W(X)
R(Y)
W(Y)
If we can prove that the given schedule is View Equivalent to its serial schedule then the given
schedule is called view Serializable.
Why we need View Serializability?
We know that a serial schedule never leaves the database in inconsistent state because there are
no concurrent transactions execution. However a non-serial schedule can leave the database in
inconsistent state because there are multiple transactions running concurrently. By checking that
a given non-serial schedule is view serializable, we make sure that it is a consistent schedule.
You may be wondering instead of checking that a non-serial schedule is serializable or not, can’t
we have serial schedule all the time? The answer is no, because concurrent execution of
transactions fully utilize the system resources and are considerably faster compared to serial
schedules.
View Equivalent
Lets learn how to check whether the two schedules are view equivalent.

Prepared by addisu s. Page 11

 Transaction processing concepts for computer science Dep’t

Two schedules T1 and T2 are said to be view equivalent, if they satisfy all the following
conditions:
1. Initial Read: Initial read of each data item in transactions must match in both schedules. For
example, if transaction T1 reads a data item X before transaction T2 in schedule S1 then in
schedule S2, T1 should read X before T2.
Read vs Initial Read: You may be confused by the term initial read. Here initial read means the
first read operation on a data item, for example, a data item X can be read multiple times in a
schedule but the first read operation on X is called the initial read. This will be more clear once
we will get to the example in the next section of this same article.
2. Final Write: Final write operations on each data item must match in both the schedules. For
example, a data item X is last written by Transaction T1 in schedule S1 then in S2, the last write
operation on X should be performed by the transaction T1.
3. Update Read: If in schedule S1, the transaction T1 is reading a data item updated by T2 then
in schedule S2, T1 should read the value after the write operation of T2 on same data item. For
example, In schedule S1, T1 performs a read operation on X after the write operation on X by T2
then in S2, T1 should read the X after T2 performs write on X.
View Serializable
If a schedule is view equivalent to its serial schedule then the given schedule is said to be View
Serializable. Lets take an example.
View Serializable Example

Lets check the three conditions of view serializability:

Initial Read
In schedule S1, transaction T1 first reads the data item X. In S2 also transaction T1 first reads the
data item X.
Lets check for Y. In schedule S1, transaction T1 first reads the data item Y. In S2 also the first
read operation on Y is performed by T1.
We checked for both data items X & Y and the initial read condition is satisfied in S1 & S2.
Final Write
In schedule S1, the final write operation on X is done by transaction T2. In S2 also transaction
T2 performs the final write on X.
Lets check for Y. In schedule S1, the final write operation on Y is done by transaction T2. In
schedule S2, final write on Y is done by T2.
We checked for both data items X & Y and the final write condition is satisfied in S1 & S2.

Prepared by addisu s. Page 12

 Transaction processing concepts for computer science Dep’t

Update Read
In S1, transaction T2 reads the value of X, written by T1. In S2, the same transaction T2 reads
the X after it is written by T1.
In S1, transaction T2 reads the value of Y, written by T1. In S2, the same transaction T2 reads
the value of Y after it is updated by T1.
The update read condition is also satisfied for both the schedules.
Result: Since all the three conditions that checks whether the two schedules are view equivalent
are satisfied in this example, which means S1 and S2 are view equivalent. Also, as we know that
the schedule S2 is the serial schedule of S1, thus we can say that the schedule S1 is view
serializable schedule.
Transaction Execution with SQL :
The American National Standards Institute (ANSI) has defined standards that govern SQL
database transactions. Transaction support is provided by two SQL statements namely COMMIT
and ROLLBACK.
The ANSI standards require that, when a transaction sequence is initiated by a user or an
application program, it must continue through all succeeding SQL statements until one of the
following four events occur :
 A COMMIT statement is reached, in which case all changes are permanently recorded
within the database. The COMMIT statement automatically ends the SQL transaction.
The COMMIT operations indicates successful end-of-transaction. 
 A ROLLBACK statement is reached, in which case all the changes are aborted and the
database is rolled back to its previous consistent state. The ROLLBACK operation
indicates unsuccessful end-of-transaction. 
 The end of a program is successfully reached, in which case all changes are permanently
recorded within the database. This action is equivalent to COMMIT. 
 The program is abnormally terminated, in which case the changes made in the database
are aborted and the database is rolled back to its previous consistent state. This action is
equivalent to ROLLBACK.

Prepared by addisu s. Page 13