Unit IV

Introduction to Transaction
Processing Concepts and Theory
 UNIT- IV
Introduction to Transaction Processing
Concepts and Theory: Introduction to
Transaction Processing- Transaction and System
Concepts- ACID Properties-Characterizing
Schedules Based on Recoverability.
 Transaction
• Transaction is a set of operations which are all
logically related
• Transaction is a single logical unit of work
formed by a set of operations
ACID properties
 ACID properties
• In order to maintain consistency in a database,
before and after transaction, certain
properties are followed. These are
called ACID properties.
1. Atomicity
2. Consistency
3. Integrity
4. Durability
 Atomicity
 Atomicity mean that either the entire
transaction takes place at once or doesn’t
happen at all.
 Atomicity is also known as the ‘All or nothing
rule’.
 Atomicity
• Consider the following transaction T consisting
of T1 and T2: Transfer of 100 from
account X to account Y.
 Consistency
• Consistency means that integrity constraints must be
maintained so that the database is consistent before and
after the transaction. It refers to 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.
 Isolation
 isolation refers to Transactions are often
executed concurrently (e.g., reading and
writing to multiple tables at the same time).
 Isolation ensures that concurrent execution of
transactions leaves the database in the same
state that would have been obtained if the
transactions were executed sequentially.
.
 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 is system failure occurs. These updates
now become permanent and are stored in a
non-volatile memory. The effects of the
transaction, thus, are never lost.
 Operations in a transaction-

1. Read Operation
2. Write Operation
 1. Read Operation

• Read operation reads the data from the

database and then stores it in the buffer of
main memory.
• For example- Read(A) instruction will read the
value of A from the database and will store it
in the buffer of main memory.
 2. Write Operation

• Write operation writes the data back to the

database from the buffer.
• For example- Write(A) will write the updated
value of A from the buffer to the database.
Transaction states
 Transaction States

• A transaction goes through many different states

throughout its lifetime. These states are known
as transaction states.
• Transaction states are as follows
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Aborted state
6. Terminated state
 System Log File
The System Log File
• Is an append-only file to keep track
of all operations of all transactions
in the order in which they occurred.
This information is needed during
recovery from failures
 Transaction and System Concepts
DBMS Recovery Manager needs system to keep
track of the following operations (in the system
log file):
• begin_transaction: Start of transaction
execution.
• read or write: Read or write operations on the
database items that are executed as part of a
transaction.
• end_transaction: Specifies end of read and
write transaction operations have ended. System
may still have to check whether the changes
(writes) introduced by transaction can be
permanently applied to the database (commit
transaction); or whether the transaction has to
be rolled back (abort transaction) because it
violates concurrency control or for some other
 Transaction and System Concepts

Recovery manager keeps track of the following

operations :
• commit_transaction: Signals successful end of
transaction; any changes (writes) executed by
transaction can be safely committed to the
database and will not be undone.
• abort_transaction (or rollback): Signals
transaction has ended unsuccessfully; any
changes or effects that the transaction may have
applied to the database must be undone.
 Transaction and System Concepts

System operations used during recovery :

• undo(X): Similar to rollback except that
it applies to a single write operation
rather than to a whole transaction.
• redo(X): This specifies that a write
operation of a committed transaction
must be redone to ensure that it has been
applied permanently to the database on
disk.
 Transaction and System Concepts
Types of records (entries) in log file:
• [start_transaction,T]: Records that transaction
T has started execution.
• [write_item,T,X,old_value,new_value]: T has
changed the value of item X from old_value to
new_value.
• [read_item,T,X]: T has read the value of item X
(not needed in many cases).
• [end_transaction,T]: T has ended execution
• [commit,T]: T has completed successfully, and
committed.
• [abort,T]: T has been aborted.
Concurrency Control
 Concurrency Control
Concurrency Control in Database Management
System is a procedure of managing simultaneous
operations without conflicting with each other.
It ensures that Database transactions are
performed concurrently and accurately to
produce correct results without violating data
integrity of the respective Database.
 Uses Of Concurrency Control
• To apply Isolation through mutual exclusion
between conflicting transactions
• To resolve read-write and write-write conflict issues
• To preserve database consistency through
constantly preserving execution obstructions
• The system needs to control the interaction among
the concurrent transactions. This control is achieved
using concurrent-control schemes.
• Concurrency control helps to ensure serializability
 Potential problems of Concurrency

• Potential problems of Concurrency

• Here, are some issues while using the DBMS Concurrency Control method:
• Lost Updates occur when multiple transactions select the same row and update
the row based on the value selected
• Uncommitted dependency issues occur when the second transaction selects a row
which is updated by another transaction (dirty read)
• Non-Repeatable Read occurs when a second transaction is trying to access the
same row several times and reads different data each time.
• Incorrect Summary issue occurs when one transaction takes summary over the
value of all the instances of a repeated data-item, and second transaction update
few instances of that specific data-item. In that situation, the resulting summary
does not reflect a correct result.
• Deadlocks:A deadlock is a condition in which two (or more) transactions in a set
are waiting simultaneously for locks held by some other transaction in the set.
 Different Types of Conflicts in transactions

• Write-Read (WR) conflict(dirty read conflict)

• Read-Write (RW) conflict(incorrect summary
issue)
• Write-Write (WW) conflict(lost update
problem)
 Write-Read (WR) conflict
• This conflict occurs when a transaction read
the data which is written by the other
transaction before committing. Here, the
transaction T2 is reading the data which is
written by the T1 before T1 commits. It is also
called as Dirty Read.
 Read-Write (RW) conflict
• Transaction T2 is Writing data which is
previously read by transaction T1.
 Write-Write (WW) conflict
• Transaction T2 is writing data which is already
written by other transaction T1. T2 overwrites
the data written by T1. It is also called as
a blind write operation.
• Data written by T1 has vanished. So it is data
update loss.
 Deadlocks
• A deadlock is a condition in which two (or more)
transactions in a set are waiting simultaneously for
locks held by some other transaction in the set.
Neither transaction can continue because each
transaction in the set is on a waiting queue, waiting for
one of the other transactions in the set to release the
lock on an item. Thus, a deadlock is an impasse that
may result when two or more transactions are each
waiting for locks to be released that are held by the
other. Transactions whose lock requests have been
refused are queued until the lock can be granted.
 Deadlocks
• Consider the following two transactions:
T1: write (X) T2: write(Y)
write(Y) write(X)
Schedule with deadlock
 Concurrency Control Protocols
• Different concurrency control protocols offer
different benefits between the amount of
concurrency they allow and the amount of
overhead that they impose. Following are the
Concurrency Control techniques in DBMS:
• Lock-Based Protocols
• Two Phase Locking Protocol
• Timestamp-Based Protocols
• Validation-Based Protocols
• optimistic protocols
 Characterizing Schedules Based on
Recoverability

• Schedules Based on Recoverability

 Schedules of Transactions
• Transaction schedule (or history): When
transactions are executing concurrently in an
interleaved fashion, the order of execution of
operations from the various transactions
forms what is known as a transaction
schedule (or history).
 Schedules of Transactions
• Schedules can also be displayed in more compact notation
• Order of operations from left to right
• Include only read (r) and write (w) operations, with
transaction id (1, 2, …) and item name (X, Y, …)
• Can also include other operations such as b (begin), e (end), c
(commit), a (abort)
• Schedules in Figure 21.5 would be displayed as follows:
– Schedule A: r1(X); w1(X); r1(Y); w1(Y); r2(X); w2(x);
– Schedule B: r2(X); w2(X); r1(X); w1(X); r1(Y); w1(Y);
– Schedule C: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
– Schedule D: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y);
 Recoverability
• recoverability refers to the ability of a system
to restore its state in the event of a failure.
The recoverability of a system is directly
impacted by the type of schedule that is used.
Schedules Based on Recoverability
 Characterizing Schedules based on
Recoverability
• Recoverable Schedule: A schedule is recoverable if it allows for the recovery of the
database to a consistent state after a transaction failure. In a recoverable schedule, a
transaction that has updated the database must commit before any other
transaction reads or writes the same data. If a transaction fails before committing,
its updates must be rolled back, and any transactions that have read its
uncommitted data must also be rolled back.
• Cascadeless Schedule: A schedule is cascaded less if it does not result in a cascading
rollback of transactions after a failure. In a cascade-less schedule, a transaction that
has read uncommitted data from another transaction cannot commit before that
transaction commits. If a transaction fails before committing, its updates must be
rolled back, but any transactions that have read its uncommitted data need not be
rolled back.
• Strict Schedule: A schedule is strict if it is both recoverable and cascades. In a strict
schedule, a transaction that has read uncommitted data from another transaction
cannot commit before that transaction commits, and a transaction that has updated
the database must commit before any other transaction reads or writes the same
data. If a transaction fails before committing, its updates must be rolled back, and
any transactions that have read its uncommitted data must also be rolled back.
 Characterizing Schedules based on
Recoverability
Schedules classified into two main classes:
• Recoverable schedule: One where no committed
transaction needs to be rolled back (aborted).
A schedule S is recoverable if no transaction T in S commits
until all transactions T’ that have written an item that T reads
have committed.
• Non-recoverable schedule: A schedule where a
committed transaction may have to be rolled back during
recovery.
This violates Durability from ACID properties (a committed
transaction cannot be rolled back) and so non-recoverable
schedules should not be allowed.
 Characterizing Schedules Based on
Recoverability
• Example: Schedule A below is non-recoverable because T2
reads the value of X that was written by T1, but then T2
commits before T1 commits or aborts
• To make it recoverable, the commit of T2 (c2) must be
delayed until T1 either commits, or aborts (Schedule B)
• If T1 commits, T2 can commit
• If T1 aborts, T2 must also abort because it read a value that
was written by T1; this value must be undone (reset to its old
value) when T1 is aborted
– known as cascading rollback

• Schedule A: r1(X); w1(X); r2(X); w2(X); c2; r1(Y); w1(Y); c1 (or a1)
• Schedule B: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y); c1 (or a1); ...
 Characterizing Schedules based on
Recoverability
Recoverable schedules can be further refined:
• Cascadeless schedule: A schedule in which a transaction
T2 cannot read an item X until the transaction T1 that last
wrote X has committed.
• The set of cascadeless schedules is a subset of the set of
recoverable schedules.

Schedules requiring cascaded rollback: A schedule in which

an uncommitted transaction T2 that read an item that was
written by a failed transaction T1 must be rolled back.
 Characterizing Schedules based on
Recoverability
• Example: Schedule B below is not cascadeless because T2
reads the value of X that was written by T1 before T1 commits
• If T1 aborts (fails), T2 must also be aborted (rolled back)
resulting in cascading rollback
• To make it cascadeless, the r2(X) of T2 must be delayed until
T1 commits (or aborts and rolls back the value of X to its
previous value) – see Schedule C

• Schedule B: r1(X); w1(X); r2(X); w2(X); r1(Y); w1(Y); c1 (or a1);

• Schedule C: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); ...
 Characterizing Schedules based on
Recoverability
Cascadeless schedules can be further refined:
• Strict schedule: A schedule in which a transaction T2 can
neither read nor write an item X until the transaction T1 that
last wrote X has committed.
• The set of strict schedules is a subset of the set of cascadeless
schedules.
• If blind writes are not allowed, all cascadeless schedules are
also strict

Blind write: A write operation w2(X) that is not preceded by a

read r2(X).
 Characterizing Schedules based on
Recoverability
• Example: Schedule C below is cascadeless and also strict
(because it has no blind writes)
• Schedule D is cascadeless, but not strict (because of the blind
write w3(X), which writes the value of X before T1 commits)
• To make it strict, w3(X) must be delayed until after T1
commits – see Schedule E

• Schedule C: r1(X); w1(X); r1(Y); w1(Y); c1; r2(X); w2(X); …

• Schedule D: r1(X); w1(X); w3(X); r1(Y); w1(Y); c1; r2(X); w2(X); …
• Schedule E: r1(X); w1(X); r1(Y); w1(Y); c1; w3(X); r2(X); w2(X); …
 Characterizing Schedules based on
Serializability
• Serial schedule: A schedule S is serial if, for every
transaction T participating in the schedule, all the
operations of T are executed consecutively (without
interleaving of operations from other transactions) in the
schedule. Otherwise, the schedule is called nonserial.
• Based on the consistency preservation property, any
serial schedule will produce a correct result (assuming no
inter-dependencies among different transactions)
Serial Schedules and Serializable Schedules

• In serial schedules, only one transaction is

allowed to execute at a time i.e. no
concurrency is allowed.
• Whereas in serializable schedules, multiple
transactions can execute simultaneously i.e.
concurrency is allowed.
• Some non-serial schedules may lead to
inconsistency of the database.
• Serializability is a concept that helps to identify
which non-serial schedules are correct and will
maintain the consistency of the database.
• Serializable Schedules-
If a given non-serial schedule of ‘n’ transactions
is equivalent to some serial schedule of ‘n’
transactions, then it is called as a serializable
schedule.
Types of Serializability-
 Types of Serializability
• Conflict serializability − A schedule is conflict
serializable if it is equivalent to some serial
schedule and does not contain any conflicting
operations.

• View serializability − A schedule is a view

serializable if it is equivalent to some serial
schedule, but the order of the transactions
may be different.