Transaction Processing

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 22

Transaction Processing

Introduction to Transaction Processing

Single-user VS multi-user systems


 A DBMS is single-user if at most one user can use the system at a time
 A DBMS is multi-user if many users can use the system concurrently
Problem
How to make the simultaneous interactions of multiple users with the database
safe, consistent, correct, and efficient?
What is Transaction

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


application program, which reads or updates the contents of the
database.
What is Transaction

 A transaction is a logical unit of work on the database. It may be an entire


program, a part of a program, or a single command (for example, the SQL
command INSERT or UPDATE), and it may involve any number of
operations on the database.
 A transaction should always transform the database from one consistent
state to another
What is Transaction

 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, ifa 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.
Transaction State
Transaction State

Active, the initial state; the transaction stays in this state while it is executing
Partially committed, after the final statement has been executed.
Failed, after the discovery that normal execution can no longer proceed.
Aborted, after the transaction has been rolled back and the database
restored to its state prior to the start of the transaction. Two options after it has
been aborted:
 restart the transaction -- only if no internal logical error
 kill the transaction
Committed, after successful completion
Properties of Transactions

ACID, properties
 Atomicity: The ‘all or nothing’ property. A transaction is
an indivisible unit that is either performed in its entirety or
is not performed at all.
 Consistency: A transaction must transform the database
from one consistent state to another consistent state. It
is the responsibility of both the DBMS and the
application developers to ensure consistency.
Properties of Transactions

ACID, properties
 Isolation: Transactions execute independently of one
another. In other words, the partial effects of
incomplete transactions should not be visible to other
transactions.
 Durability The effects of a successfully completed
(committed) transaction are permanently recorded in
the database and must not be lost because of a
subsequent failure.
Example of Fund Transfer
Example of Fund Transfer

Consistency requirement – the sum of A and B is unchanged by the


execution of the transaction.
Atomicity requirement — if the transaction fails after step 3 and before
step 6, the system should ensure that its updates are not reflected in
the database, else an inconsistency will result.
Durability requirement — once the user has been notified that the
transaction has completed (i.e., the transfer of the $50 has taken
place), the updates to the database by the transaction must persist
despite failures.
Isolation requirement — if between steps 3 and 6, another transaction
is allowed to access the partially updated database, it will see an
inconsistent database (the sum A + B will be less than it should be).
Concurrency Control

 The process of managing simultaneous operations on the database


without having them interfere with one another.

 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

 Three problems are


1. The lost update problem
2. The uncommitted dependency (or dirty read) problem
3. The inconsistent analysis problem
4. Nonrepeatable (or fuzzy) read
The lost update problem

 An apparently successfully completed update operation by one user can


be overridden by another user. This is known as the lost update problem
The uncommitted dependency (or
dirty read) problem

 The uncommitted dependency problem occurs when one transaction is


allowed to see the intermediate results of another transaction before it has
committed.
The inconsistent analysis problem

 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.
Nonrepeatable (or fuzzy) read

 Another problem can occur when a transaction T rereads a data item it


has previously read but, in between, another transaction has modified it.
 Thus, T receives two different values for the same data item. This is
sometimes referred to as a nonrepeatable (or fuzzy) read.
 A similar problem can occur if transaction T executes a query that
retrieves a set of tuples from a relation satisfying a certain predicate, re-
executes the query at a later time but finds that the retrieved set contains
an additional (phantom) tuple that has been inserted by another
transaction in the meantime. This is sometimes referred to as a phantom
read.
Serializability

 The objective of a concurrency control protocol is to schedule transactions


in such a way as to avoid any interference between them,
 Allow only one transaction to execute at a time: one transaction is
committed before the next transaction is allowed to begin.
 Maximize the degree of concurrency or parallelism in the system, so that
transactions that can execute without interfering with one another can run
in parallel.
Serializability

 Schedule A sequence of the operations by a set of concurrent


transactions that preserves the order of the operations in each of the
individual transactions.
 Serial schedule A schedule where the operations of each transaction are
executed consecutively without any interleaved operations from other
transactions.
 Nonserial schedule A schedule where the operations from a set of
concurrent transactions are interleaved.
Serializability

 If a set of transactions executes concurrently (nonserial) schedule is


correct if it produces the same results as some serial execution. Such a
schedule is called serializable. In serializability, the ordering of read and
write operations is important:
 If two transactions only read a data item, they do not conflict and order is not
important.
 If two transactions either read or write completely separate data items, they do
not conflict and order is not important.
 If one transaction writes a data item and another either reads or writes the same
data item, the order of execution is important.
Concurrency control techniques

 Locking: A procedure used to control concurrent access to data. When


one transaction is accessing the database, a lock may deny access to
other transactions to prevent incorrect results.
 Shared lock: If a transaction has a shared lock on a data item, it can read
the item but not update it.
 Exclusive lock: If a transaction has an exclusive lock on a data item, it can
both read and update the item.
Concurrency control techniques

 Time stamping: A concurrency control protocol that orders transactions in


such a way that older transactions, transactions with smaller timestamps,
get priority in the event of conflict.

You might also like