DATABASE

SYSTEMS (Transaction
Management)
INSTRUCTOR : FARHAN SARWAR
 Topics to Cover

 What is Transaction?

 Transaction States

 Properties of Transactions

 Concurrency control and why it is needed?

 The lost update

 The dirty read problem

 The inconsistent analysis problem

 Why recovery is needed?

 Types of failures
 Transaction

 An action, or series of actions, carried out by a single user or application

program, that reads or updates the contents of the database.
 A transaction can be defined as an indivisible unit of work comprised of
several operations, all or none of which must be performed in order to
preserve data integrity.
 A transaction includes one or more database access operations—these can
include insertion, deletion, modification (update), or retrieval operations.
 Transaction

 A transaction is a unit of work that is performed against a database.

 Transactions are units or sequences of work accomplished in a logical order,
whether in a manual fashion by a user or automatically by some sort of a
database program.
 A transaction is the propagation of one or more changes to the database. For
example, if you are creating a record or updating a record or deleting a record
from the table, then you are performing a transaction on that table. It is
important to control these transactions to ensure the data integrity and to handle
database errors.
 Transaction

Using this simplified database model, the basic database access operations that
a transaction can include are as follows:
 read_item(X,Access). Reads a database item named X into a program
variable.

 write_item(X,Change). Writes the value of program variable X into the

database item named X.
Transaction States
 Transaction States

 A transaction can have one of two outcomes. If it completes successfully, the

transaction is said to have committed and the database reaches a new
consistent state.
 On the other hand, if the transaction does not execute successfully, the
transaction is aborted. If a transaction is aborted, the database must be
restored to the consistent state it was in before the transaction started.
 Such a transaction is rolled back or undone. A committed transaction
cannot be aborted.
 Transaction States

 PARTIALLY COMMITTED, which occurs after the final statement has been
executed.
 At this point, it may be found that the transaction has violated an integrity
constraint and the transaction has to be aborted.
 Alternatively, the system may fail and any data updated by the transaction may
not have been safely recorded on secondary storage.
 In such cases, the transaction would go into the FAILED state and would have
to be aborted.
 FAILED, which occurs if the transaction cannot be committed or the
transaction is aborted while in the ACTIVE state, perhaps due to the user
aborting the transaction.
 Properties of Transactions (ACID)

 Transactions have the following four standard properties, usually referred to by the
acronym ACID.
 Atomicity(Either all or None) − ensures that all operations within the work unit are
completed successfully. Otherwise, the transaction is aborted at the point of failure
and all the previous operations are rolled back to their former state.
 Consistency − ensures that the database properly changes states upon a successfully
committed transaction. For example, Before transaction start and after the
transaction completed sum of the money should be same.
 Isolation − enables transactions to operate independently of and transparent to each
other. In which multiple transaction runs parallel.
 Durability − In which all the changes are permanent and ensures that the result or
effect of a committed transaction persists in case of a system failure.
 Concurrency Control

 The process of managing simultaneous operations on the

database without having them interfere with one another.

 Concurrency control is a database concept that manages

simultaneous access to shared resources, ensuring data
integrity and consistency. It prevents conflicts and errors
when multiple users or processes access the same data
simultaneously.
 Why Concurrency Control Is
Needed?

 A major objective in developing a database is to enable many users to access

shared data concurrently.
 Concurrent access is relatively easy if all users are only reading data, as there
is no way that they can interfere with one another.
 However, when two or more users are accessing the database simultaneously
and at least one is updating data, there may be interference that can result in
inconsistencies.
 Why Concurrency Control Is
Needed?

 The system begins executing the first transaction until it reaches an I/O
operation.
 While the I/O is being performed, the CPU suspends the first transaction and
executes commands from the second transaction.
 When the second transaction reaches an I/O operation, control then returns to
the first transaction and its operations are resumed from the point at which it
was suspended.
 Why Concurrency Control Is
Needed?

 The first transaction continues until it again reaches another I/O operation.
 In this way, the operations of the two transactions are interleaved to achieve
concurrent execution. In addition, throughput ( the amount of work that is
accomplished in a given time interval ) is improved as the CPU is executing
other transaction instead of being in an idle state waiting for I/O operations to
complete.
Why Concurrency Control Is
Needed?

 We need concurrency control for several reasons:

 1. Data Integrity: Prevents data corruption and ensures consistency
when multiple users access and modify data simultaneously.
 2. Prevents Conflicts: Resolves conflicts that arise when multiple
users try to update the same data simultaneously.
 3. Maintains Consistency: Ensures that database transactions follow
the ACID properties (Atomicity, Consistency, Isolation, Durability).
 4. Improves Performance: Enables simultaneous access to resources,
increasing overall database performance and throughput.
Why Concurrency Control Is
Needed?
 5. Supports Collaborative Environments: Allows multiple users to
collaborate on shared data without conflicts or data loss.
 6. Prevents Race Conditions: Ensures that concurrent transactions execute
in a predictable and reliable order.
 7. Reduces Errors: Detects and resolves conflicts, reducing errors and
inconsistencies in the database.
 8. Ensures Reliability: Provides a robust and reliable database system that
can handle concurrent access and modifications.
 Without concurrency control, databases would be prone to data corruption,
inconsistencies, and errors, making it essential for ensuring data reliability
and integrity in multi-user environments.
Example

 Suppose we have a bank account with a initial balance of $1000. Two

transactions occur simultaneously:
 Transaction 1: Withdraw $500Transaction
 2: Deposit $300Without concurrency control, the following scenario might
occur:
 1. Transaction 1 reads the initial balance ($1000)
 2. Transaction 2 reads the initial balance ($1000)
 3. Transaction 1 subtracts $500, leaving a balance of $500
 4. Transaction 2 adds $300, leaving a balance of $1300 (using the initial balance)
 The final balance would be $1300, which is incorrect. The correct balance should
be $800 ($1000 - $500 + $300).
Example

 With concurrency control, the database would detect the conflict and resolve it
using techniques like locking, time-stamping, or versioning.
 The correct sequence would be:
 1. Transaction 1 reads the initial balance ($1000)
 2. Transaction 1 subtracts $500, leaving a balance of $500
 3. Transaction 2 reads the updated balance ($500)
 4. Transaction 2 adds $300, leaving a balance of $800
 Concurrency control ensures that transactions occur in a predictable and
reliable order, maintaining data integrity and consistency.
 Problems due to Concurrency

We examine three examples of potential problems caused by concurrency:

 the lost update problem,
 the uncommitted dependency problem (dirty read problem)
 the inconsistent analysis problem
 The Lost Update Problem

 A lost update occurs when two different transactions are trying to update the
same column on the same row within a database at the same time.
 Typically, one transaction updates a particular column in a particular row,
while another that began very shortly afterward did not see this update before
updating the same value itself.
 The result of the first transaction is then “lost”, as it is simply overwritten by
the second transaction.
The Lost Update Problem
Example 1
The Lost Update Problem
Example 2
The Uncommitted Dependency
(dirty read) Problem

 A dirty read occurs when one

transaction is permitted to read data
that is being modified by another
transaction which is running
concurrently but which has not yet
committed itself.
The Uncommitted Dependency
(dirty read) Problem
Example 1
The Uncommitted Dependency
(dirty read) Problem
Example 2
 The Inconsistent Analysis Problem

 This problem is caused when one of the transactions is executing an

aggregate operation on several data items, and other transactions are updating
one or more of those data items. This causes a inconsistent database state.
 The problem of inconsistent analysis occurs when a transaction reads several
values from the database but a second transaction updates some of them
during the execution of the first.
The Inconsistent Analysis Problem
Example 1
The Inconsistent Analysis
Problem Example 2
 Why Recovery is Needed?

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

system is responsible for making sure that either all the operations
in the transaction are completed successfully and their effect is
recorded permanently in the database, or that the transaction does
not have any effect on the database or any other transactions.
 Why Recovery is Needed?

 In the first case, the transaction is said to be committed, whereas in the

second case, the transaction is aborted.
 The DBMS must not permit some operations of a transaction T to be applied
to the database while other operations of T are not, because the whole
transaction is a logical unit of database processing.
 If a transaction fails after executing some of its operations but before
executing all of them, the operations already executed must be undone and
have no lasting effect.
 Types of Failures

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. Transaction
failure may also occur because of erroneous parameter values or because of
a logical programming error.
 Types of Failures

 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,4 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
 Types of Failures

 4. Concurrency control enforcement. The concurrency control method

may abort a transaction to resolve a state of deadlock among several
transactions. Transactions aborted because of 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.
NEXT LECTURE

 Serializability
 Recoverability
 Algorithms to remove
concurrency problems