MODULE – 4

CHAPTER-11

TRANSACTION PROCESSING
Transaction processing:
The concept of transaction provides a mechanism for describing logical
units of database processing.
Transaction processing systems are systems with large databases and
hundreds of concurrent users executing database transactions.
Examples of such systems include airline reservations, banking, credit
card processing, online retail purchasing, stock markets, supermarket
checkouts, and many other applications.
These systems require high availability and fast response time for
hundreds of concurrent users.

Introduction to Transaction Processing:

DBMS is classified according to the number of users who can use the system
concurrently that is,

1. Single user

2. Multiuser.

Single - User:
o At most one user at a time can use the system.
o Single-user DBMSs are mostly restricted to personal computer
systems.
Multi-User:

o Many users can use the system and hence access the database
concurrently.
o Database systems used in banks, insurance agencies, stock exchanges,
supermarkets, airline agencies and many other applications are multiuser
systems.
o Multiple users can access databases and use computer system
simultaneously because of the concept of multiprogramming (to execute
multiple programs or processes at the same time).
o In a multiuser DBMS, the stored data items are the primary resources that
may be accessed concurrently by users or programs, which are constantly
retrieving information from and modifying the database.

Interleaved processing versus parallel processing of concurrent

transactions:
o Multiprogramming operating systems execute some commands from one
process, then suspend that process and execute some commands from
the next process, and so on. A process is resumed at the point where it
was suspended whenever it gets its turn to use the CPU again. Hence,
concurrent execution of processes is actually interleaved.
Interleaving prevents a long process from delaying other processes.

o If the computer system has multiple hardware processors (CPUs),

parallel processing of multiple processes is possible.
 For example,

o Two processes, A and B, executing concurrently in an interleaved fashion.

Interleaving keeps the CPU busy when a process requires an input or
output (I/O) operation, such as reading a block from disk. The CPU is
switched to execute another process rather than remaining idle during
I/O time.
o Parallel processing of multiple processes is illustrated by processes C and
D using multiple CPUs.

Transactions, Database Items, Read and Write Operations, and

DBMS Buffers:-
Transactions:
A transaction is an executing program that forms a logical unit of database
processing.
 A transaction includes one or more database access operations, they are,
insertion, deletion, modification (update), or retrieval operations.
The database operations that form a transaction can either be
embedded within an application program or they can be specified
interactively via a high-level query language such as SQL.
One way of specifying the transaction boundaries is by specifying explicit
begin transaction and end transaction statements.
If the database operations in a transaction do not update the database but
only retrieve data, the transaction is called a read-only transaction;
otherwise it is known as a read-write transaction.

Database items:
A database is basically represented as a collection of named data items.
The size of a data item is called its granularity.
A data item can be a database record, but it can also be a larger unit
such as a whole disk block, or even a smaller unit such as an individual
field (attribute) value of some record in the database.
Each data item has a unique name, used to uniquely identify each data
item.
For example, if the data item granularity is one disk block, then the disk
block address can be used as the data item name. If the item
granularity is a single record, then the record ID can be the item name.
Read and write operations:
read_item(X)-Reads a database item named X into a program variable. To
simplify our notation, we assume that the program variable is also
named X.
write_item(X)-Writes the value of program variable X into the database
item named X.

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

1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory (if that disk block is
not already in some main memory buffer). The size of the buffer is the
same as the disk block size.
3. Copy item X from the buffer to the program variable named X.

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

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

A transaction includes read_item and write_item operations to access and

update the database.
Buffers:

Sometimes the buffer is not immediately stored to disk, in case

additional changes are to be made to the buffer.
The decision about when to store a modified disk block whose contents
are in a main memory buffer is handled by the recovery manager of the
DBMS in cooperation with the underlying operating system.
The DBMS will maintain in the database cache a number of data buffers in
main memory.
Each buffer typically holds the contents of one database disk block, which
contains some of the database items being processed. When these buffers
are all occupied, and additional database disk blocks must be copied into
memory, some buffer replacement policy is used that is LRU(least recently
used).If the chosen buffer has been modified, it must be written back to
disk before it is reused.

Why Concurrency Control Is Needed:

 Several problems can occur when concurrent transactions execute in an uncontrolled manner.
 We illustrate some of these problems by referring to a much simplified airline reservations database in
which a record is stored for each airline flight. Each record includes the number of reserved seats on that
flight as a named (uniquely identifiable) data item, among other information. Figure 20.2(a) shows a
transaction T1 that transfers N reservations from one flight whose number of reserved seats is stored in the
database item named X to another flight whose number of reserved seats is stored in the database item
named Y. Figure 20.2(b) shows a simpler transaction T2 that just reserves M seats on the first flight (X)
referenced in transaction T1.2
 To simplify our example, we do not show additional portions of the transactions, such as checking whether a
flight has enough seats available before reserving additional seats. When a database access program is
written, it has the flight number, the flight date, and the number of seats to be booked as parameters; hence,
the same program can be used to execute many different transactions, each with a different flight number,
date, and number of seats to be booked. For concurrency control purposes, a trans action is a particular
execution of a program on a specific date, flight, and number of seats.

In Figures 20.2(a) and (b), the

transactions T1 and T2 are specific
executions of the programs that refer to
the specific flights whose numbers of
seats are stored in data items X and Y in
the database.
 Several problems can occur when concurrent transactions execute in an
uncontrolled manner. We illustrate some of these problems they are,
1. The Lost Update Problem:
This problem occurs when two transactions that access the same
database items have their operations interleaved in a way that makes
the value of some database items incorrect. Suppose that transactions
T1 and T2 are submitted at the same time, and their operations are
interleaved as shown in Figure(a); then the final value of item X is
incorrect because T2 reads the value of X before T1 changes it in the
database, and hence the updated value resulting from T1 is lost.

For example,
If X = 80 at the start (originally there were 80 reservations on the flight), N = 5 (T1 transfers 5 seat
reservations from the flight corresponding to X to the flight corresponding to Y), and M = 4 (T2 reserves
4 seats on X), the final result should be X = 79. However, in the interleaving of operations shown in
Figure (a), it is X = 84 because the update in T1 that removed the five seats from X was lost

2. The Temporary Update (or Dirty Read) Problem:

This problem occurs when one transaction updates a database item
and then the transaction fails for some reason. Meanwhile, the
updated item is accessed (read) by another transaction before it is
changed back (or rolled back) to its original value.
Figure (b) shows an example where T1 updates item X and then fails before completion, so the system
must roll back X to its original value. Before it can do so, however, transaction T2 reads the temporary
value of X, which will not be recorded permanently in the database because of the failure of T1. The
value of item X that is read by T2 is called dirty data because it has been created by a transaction that
has not completed and committed yet; hence, this problem is also known as the dirty read problem.

3. The Incorrect Summary Problem:

If one transaction is calculating an aggregate summary function on a
number of database items while other transactions are updating some
of these items, the aggregate function may calculate some values
before they are updated and others after they are updated.

For example,
suppose that a transaction T3 is calculating the total number of reservations on all the flights;
meanwhile, transaction T1 is executing. If the interleaving of operations shown in Figure 20.3(c) occurs,
the result of T3 will be off by an amount N because T3 reads the value of X after N seats have been
subtracted from it but reads the value of Y before those N seats have been added to it.
4.The Unrepeatable Read Problem:
Another problem that may occur is called unrepeatable read, where a
transaction T reads the same item twice and the item is
changed by another transaction T′ between the two reads. Hence, T
receives different values for its two reads of the same item. This may
occur, for example, if during an airline reservation transaction, a
customer inquires about seat availability on several flights. When the
customer decides on a particular flight, the transaction then reads the
number of seats on that flight a second time before completing the
reservation, and it may end up reading a different value for the item.
Why Recovery Is Needed:-

Whenever a transaction is submitted to a DBMS for execution, the system

is responsible for making sure that either all the operations in the
transaction are completed successfully, then the transaction is said to be
committed.
And their effect is recorded permanently in the database, or that the
transaction does not have any effect on the database or any other
transactions, and then the transaction is aborted.
If a transaction fails after executing some of its operations but before
executing all of them, the operations already executed must be undone
and have no lasting effect.

Types of Failures:-
Failures are generally classified as transaction, system, and media failures. There
are several possible reasons for a transaction to fail in the middle of execution:

1. A computer failure (system crash)-

A hardware, software, or network error occurs in the computer system during
transaction execution. Hardware crashes are usually media failures for example,
main memory failure.
 2. A transaction or system error-
Some operation in the transaction may cause it to fail, such as integer
overflow or division by zero, erroneous parameter values or because of a
logical programming error. Additionally, the user may interrupt the transaction
during its execution.

3. Local errors or exception conditions detected by the transaction-

During transaction execution, certain conditions may occur that necessitate
cancellation of the transaction. For example, data for the transaction may not be
found. An exception condition, such as insufficient account balance in a banking
database, may cause a transaction, such as a fund withdrawal, to be canceled.
This exception could be programmed in the transaction itself, and in such a case
would not be considered as a transaction failure.

4. Concurrency control enforcement-

The concurrency control method may abort a transaction because it violates
serializability, or it may abort one or more transactions to resolve a state of
deadlock among several transactions. Transactions aborted because of
serializability violations or deadlocks are typically restarted automatically at a
later time.
 5. Disk failure-
Some disk blocks may lose their data because of a read or write malfunction or
because of a disk read/write head crash. This may happen during a read or a
write operation of the transaction.

6. Physical problems and catastrophes-

This refers to an endless list of problems that includes power or air-
conditioning failure, fire, theft, sabotage, overwriting disks or tapes by mistake,
and mounting of a wrong tape by the operator.

Whenever a failure of type 1 through 4 occurs, the system must keep sufficient
information to quickly recover from the failure. Disk failure or other catastrophic
failures of type 5 or 6 do not happen frequently; if they do occur, recovery is a
major task.