Introduction to Transaction

Processing Concepts and Theory

Copyright © 2016 Ramez Elmasri and Shamkant B.

Navathe
Introduction
■ Transaction
■ Describes logical unit of database processing
■ Transaction processing systems
■ Systems with large databases and hundreds of concurrent users
■ Require high availability and fast response time

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 2

 Introduction
■ Desirable Properties of a Transaction
■ Atomicity
■ A transaction is an atomic unit of processing; it should either be performed in its entirety or
not performed at all
■ Consistency
■ If transaction is executed completely without any interference - it must take the database
from one consistent state to another.
■ Isolation
■ Transaction should appear as though it is being executed in isolation from other
transactions, even though many transactions are executing concurrently.
■ Durability
■ The changes applied to the database by a committed transaction must persist in the
database. These changes must not be lost because of any failure.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 3

Introduction to Transaction Processing
Classify the database systems
according to the no. of users who can
use the system concurrently

Single User Multi User

■ At most one user at ■ Many users
a time can use the access the
system. system
■ Eg: personal concurrently Eg:
computer banks
Introduction to Transaction Processing (cont’d.)

■ Multiprogramming
■ Allows operating system to execute multiple processes concurrently
■ Executes commands from one process, then suspends that process and executes
commands from another process, etc.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 6

■ Multiple users can access the database because of the concept of
multiprogramming.

Two Types of processing of concurrent

transactions

Interleaved Parallel
processing processing
 Introduction to Transaction Processing (cont’d.)
■ Interleaved processing
■ Processes A and B
■ Parallel processing
■ Processes C and D

Figure 20.1 Interleaved processing versus parallel processing of concurrent transactions

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 8

Transaction: is an executing program that forms a logical unit of database
processing. A transaction includes one or more database access operations these
can include insertion, deletion, modification, or retrieval operations.
• Transaction boundaries: explicit begin transaction and end transaction statements
in an application program.
begin transaction
One transaction
end transaction

• Two types of transactions: Read only Transaction and Read Write Transaction
Database
• Database: collection of named data items.

• Granularity: size of data item is called its granularity

Database Items
■ Database represented as collection of named data items
■ Size of a data item called its granularity
■ Data item
■ Record
■ Disk block
■ Attribute value of a record
■ Transaction processing concepts independent of item granularity

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 10

Read and Write Operations
■ read_item(X)
■ Reads a database item named X into a program variable named X
■ Process includes finding the address of the disk block, and copying to
and from a memory buffer
■ write_item(X)
■ Writes the value of program variable X into the database item named X
■ Process includes finding the address of the disk block, copying to and
from a memory buffer, and storing the updated disk block back to disk

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 11

Steps for executing a read_item(X)
1. Find the address of the disk block that contains item X.
Disk block
address contains X

2. Copy that disk block into a buffer in main memory (if that disk block is not already in
some main memory buffer).
Main memory Copy
Buffer Contains X

3. Copy item X from the buffer to the program variable named X.

Copy(item X)
Program variable Buffer
X
Steps for executing a write_item(X)
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.
Program Copy(item X)
variable X Buffer

4.Store the updated block from the buffer back to disk (either immediately or at some later
point in time).
Copy
Buffer Disk block
contains X
Read and Write Operations (cont’d.)
■ Read set of a transaction
■ Set of all items read
■ Write set of a transaction
■ Set of all items written

Figure 20.2 Two sample transactions (a) Transaction T1 (b) Transaction T2

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 14

DBMS Buffers
■ DBMS will maintain several main memory data buffers in the database
cache
■ When buffers are occupied, a buffer replacement policy is used to choose
which buffer will be replaced
■ Example policy: least recently used

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 15

Example

• The read_set of a transaction is the set of all items that the transaction reads
• The write_set is the set of all items that the transaction write
28 April 2025 Dept. Of I&CT 16
Why is Concurrency control needed?
• 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

28 April 2025 Dept. Of I&CT 17

Why is Concurrency control needed?
• The temporary Update (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 by another transaction before it is changed back to
its original value

28 April 2025 Dept. Of I&CT 18

Why is Concurrency control needed?
• 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 functions
may calculate some values before they are
updated and others after they are updated.

28 April 2025 Dept. Of I&CT 19

Why is Concurrency control needed?

• The Unrepeatable Read Problem: It is problem where a transaction T reads the

same item twice and the item is changed by another transaction T’ between the two reads

28 April 2025 Dept. Of I&CT 20

Why is recovery needed?
• Whenever a transaction is submitted to a DBMS for execution, the system is
responsible for making sure that
• Committed transaction: all the operations in the transaction are completed successfully
and their effect is recorded permanently in the database
• Aborted transaction: Does not affect the database
• Types of transaction failures
• Computer failure (system crash)
• Transaction or system error
• Local errors or exception conditions detected by the transaction
• Concurrency control enforcement
• Disk Failure

28 April 2025 Dept. Of I&CT 21

Why is recovery needed?

• 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

28-Apr-25 Dept. of I&CT 22

 Transaction
or System
failure

• H/w or S/W failures, main memory failure

Computer
Types of Failure or
Failure System Crash

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 23

 Local
errors

• Integer overflow or divide by zero, logical

Transaction
Types of or System
programming error, interruption by user

failure
Failure

Computer
Failure or
System Crash

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 24

 Concurrency
Control
Enforcement

• Exception conditions detected by the

transaction: During transaction execution,
certain conditions may occur that necessitate
Types of Local
Errors
cancellation of the transaction
• Example: exception condition, such as
Failure insufficient account balance in a banking
database, or data for the transaction may not be
found and so on.

Transaction or
System failure

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 25

 Disk
Failure

• The concurrency control method may decide to

Concurrency abort a transaction because it violates
Types of Control serializability
Enforcement
Failure • It may abort one or more transactions to resolve
a state of deadlock among several transactions

Local Errors

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 26

 Physical
problems
/catastrop
hes

• Some disk blocks may lose their data because

Types of Disk
Failure
of a read or write malfunction or because of a
disk read/write head crash
Failure

Concurrency
Control
Enforcement

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 27

 • Power or air-conditioning failure, fire,
Physical theft, sabotage, overwriting disks, or
Types of problems / tapes by mistake, and mounting of a
Catastorphes
Failure wrong tape by the operator.

Disk Failure

28-Apr-25 MAHE-ISAC CoE for Cybersecurity 28

Transaction States
Read, Write

Begin End
Transaction Transaction Commit
Active Partially Committed
Committed

Abort

Abort Commit
Terminated
Failed

28-Apr-25 Dept. of I&CT 29

System Log

• System maintains a log to keep track of all transaction information that may be
needed to permit recovery from failures
• Log is sequential – append-only file
• Log Records – entries written into the log file

28 April 2025 Dept. Of I&CT 30

Log Records
• [start_transaction, T]: Indicates that transaction T has started execution
• [write_item, T, X, old_value, new_value]: Indicates that transaction T has
changed the value of database item X from old_value to new_value.
• [read_item, T, X]: Indicates that transaction T has read the value of database
item X
• [commit, T]: Indicates that transaction T has completed successfully, and
affirms that its effect can be committed (recorded permanently) to the database
• [abort, T]:

28 April 2025 Dept. Of I&CT 31

Schedules of Transactions
• A schedule (or history) S of n transactions T1, T2, …, Tn is an ordering of
the operations from all the transactions
• For each transaction Ti that participates in the schedule S,
• the operations of Ti in S must appear in the same order in which they occur in Ti
• Total ordering of operations - meaning - for any two operations in the
schedule, one must occur before the other
• Shorthand notation for describing a schedule uses the symbols b, r, w, e, c, mbols and a for
the operations begin_transaction, read_item, write_item, end_transaction, commit, and
abort, respectively, and appends as subscript the transaction id (transaction number) to each
operation in the schedule.

28 April 2025 Dept. Of I&CT 32

Schedules of Transactions

• Shorthand Notation: Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y)

28 April 2025 Dept. Of I&CT 33
Schedules of Transactions
• Two operations are said to conflict if they satisfy all three of the following conditions:
1. They belong to different transactions
2. They access the same item X
3. At least one of the operations is a write_item(X)
• Two operations are conflicting if changing their order can result in a different
outcome
• Example: r1(X); w2(X); or w2(X); r1(X);
• This is called read-write conflict
• Write-write conflict
• Read-read?
28 April 2025 Dept. Of I&CT 34
Schedules of Transactions
• A schedule S of n transactions T1, T2, …, Tn is said to be a complete schedule
if the following conditions hold:
• The operations in S are exactly those operations in T1, T2, … Tn, including a commit or
abort operation as the last operation for each transaction in the schedule.
• For any pair of operations from the same transaction Ti, their relative order of
appearance in S is the same as their order of appearance in Ti.
• For any two conflicting operations, one of the two must occur before the other in the
schedule.
• Once a transaction T is committed, it should never be necessary to roll back T –
ensures durability

28 April 2025 Dept. Of I&CT 35

Schedules of Transactions: Classification

28 April 2025 Dept. Of I&CT 36

 Schedules of Transactions: Classification

RECOVERABILITY
Recoverability is an
important feature of
database systems that
ensures the database
can return to a
consistent and
reliable state after a
failure or error.
28 April 2025 Dept. Of I&CT 37
Schedules of Transactions: Recoverable Schedule
• Schedules in which transactions commit only after all transactions whose
changes they read commit are called recoverable schedules.
• In other words, if some transaction Tj is reading value updated or written by some other
transaction Ti , then the commit of Tj must occur after the commit of Ti .

T1 T2 T1 T2 T1 T2 T1 T2 T1 T2
R(A) R(A) R(A) R(A) R(A)
W(A) W(A) W(A) W(A) W(A)
R(A) R(A) R(A) R(A) C

W(A) R(B) W(A) R(A)

W(A) Fail W(A)
C R(B)
C C C
C W(A)
Fail C
W(B)
C
C
C

28 April 2025 Dept. Of I&CT 38

Schedules of Transactions
• A schedule S is said to be recoverable if no transaction T in S commits until all transactions
T’ that have written some item X that T reads, have committed.

• A recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj
reads a data item previously written by Ti, and the commit operations of Ti appears before
the commit operations of Tj

• A transaction T reads from transaction T’ in a schedule S if some item X is first written by

T’ and later read by T.

• T’ should not have been aborted before T reads item X, and there should be no transaction
that writes X after T’ writes it and before T reads it.
28 April 2025 Dept. Of I&CT 39
Schedules based on Recoverability
• Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;
• Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;
• Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;
• Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;
• In a recoverable schedule, no committed transaction ever needs to be rolled
back, and so the definition of committed transaction as durable is not violated.

28 April 2025 Dept. Of I&CT 40

Schedules based on Recoverability
• Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;  Recoverable but
suffers from lost update
• Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;  T2 commits before T1 and T1
aborts – not recoverable
• Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;
• Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;
• In a recoverable schedule, no committed transaction ever needs to be rolled
back, and so the definition of committed transaction as durable is not violated.

28 April 2025 Dept. Of I&CT 41

Schedules based on Recoverability
T1 T2 T3
• Cascading rollback (cascading abort) R(A) T3
occurs in some recoverable schedules, R(B)
where an uncommitted transaction has to be
W(A)
rolled back because it read an item from a
R(A)
transaction that failed.
W(A)

R(A)

28 April 2025 Dept. Of I&CT 42

Cascadeless schedules
• A schedule is said to be cascadeless or to avoid cascading rollback
• If every transaction in the schedule reads only items that were written by committed
transactions.

Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;

Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;
r2(X) command in schedules Sd and Se must be postponed until after T1 has
committed (or aborted), thus delaying T2 but ensuring no cascading rollback if
T1 aborts.
• A strict schedule is one in which transactions can neither read nor write an
item X until the last transaction that wrote X has committed (or aborted)
28 April 2025 Dept. Of I&CT 43
S1: R1(x), W1(x), R2(x), R1(y), R2(y), W2(x), W1(y), C1, C2;
S2: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), W3(y), R2(y), W2(z), W2(y), C1, C2, C3;
S3: R1(x), R2(z), R3(x), R1(z), R2(y), R3(y), W1(x), C1, W2(z), W3(y), W2(y), C3, C2;
S4: R1(x), R2(x), R1(z), R3(x), R3(y), W1(x), C1, W3(y), C3, R2(y), W2(z), W2(y), C2;

28 April 2025 Dept. Of I&CT 44

 Serializability
• A schedule S is serial if, for every transaction T participating in the schedule, all the
operations of T are executed consecutively in the schedule; otherwise, the schedule is
non-serial
• In a serial schedule, only one transaction at a time is active – the commit (or abort) of the
active transaction initiates execution of the next transaction
• No interleaving occurs in a serial schedule
• The concept of serializability of schedules is used to identify which schedules are correct
when transaction executions have interleaving of their operations in the schedules.

28 April 2025 45
Serializability
• The problem with serial schedules is that they limit concurrency by
prohibiting interleaving of operations
• If we can determine which other schedules are equivalent to a serial schedule,
we can allow these to occur

28 April 2025 Dept. Of I&CT 46

Serializable Schedule
• A schedule S of n transactions is serializable if it is
equivalent to some serial schedule of the same n
transactions
• Two schedules are called result equivalent if they
produce the same final state of the database
• Schedule equivalence: the operations applied to
each data item affected by the schedules in the same
order.
• Two definitions: Conflict Equivalence and View
Equivalence

28 April 2025 Dept. Of I&CT 47

Conflict Equivalence
• Two schedules are said to be conflict equivalent if the order of any two conflicting
operations is the same in both schedules.
• If a schedule S can be transformed into a schedule S’ by a series of swaps of non-
conflicting instructions, we say that S and S’ are conflict equivalent
• We say that a schedule S is conflict serializable if it is conflict equivalent to a serial
schedule.

28 April 2025 Dept. Of I&CT 48

Conflict Serializability (Cont.)
• Schedule 3 can be transformed into Schedule 6, a serial schedule where T2 follows T1, by series of
swaps of non-conflicting instructions.
• Schedule 3 is conflict serializable.

Schedule 3 Schedule 6
Test for Conflict Serializability
Algorithm
1. For each transaction Ti participating in schedule S, create a node labelled Ti in the
precedence graph
2. For each case in S where Tj executes a read_item(X) after Ti executes a write_item(X),
create an edge (TiTj) in the precedence graph
3. For each case in S where Tj executes a write_item(X) after Ti executes and read_item(X),
create an edge (TiTj) in the precedence graph
4. For each case in S where Tj executes a write_item(X) after Ti executes a write_item(X),
create an edge (TiTj) in the precedence graph
5. The schedule S is serializable if and only if the precedence graph has no cycles

28 April 2025 Dept. Of I&CT 50

Precedence Graph
• Precedence graph or serialization graph which is a directed graph G = (N, E) that consists of
a set of Nodes N = {T1, T2, … Tn} and a set of directed edges E = {e1, e2, …, en}
• There is one node in the graph for each transaction Ti in the schedule
• Each edge ei in the graph is of the form (Tj  Tk), 1<=j<=n, 1<=k<=n, where Tj is the
starting node of ei and Tk is the ending node of ei
• Such an edge from Tj to Tk is created by the algorithm if one of the operations in Tj appears
in the schedule before some conflicting operations in Tk

28 April 2025 Dept. Of I&CT 51

Precedence Graph
• A cycle in a directed graph is a sequence of edges C = ((TjTk),
(TkTp),…(TiTj)) with a property that the starting node of each edge –
except the first edge – is the same as the ending node of the last edge

28 April 2025 Dept. Of I&CT 52

Precedence Graph
• If there is no cycle in the precedence graph, we can create an equivalent serial
schedule S’ that is equivalent to S, by ordering the transactions that participate
in S

28 April 2025 Dept. Of I&CT 53

Example

28 April 2025 Dept. Of I&CT 54

Example

28 April 2025 Dept. Of I&CT 55

Example

28 April 2025 Dept. Of I&CT 56

Example

28 April 2025 Dept. Of I&CT 57

Example

28 April 2025 Dept. Of I&CT 58

Example

28 April 2025 Dept. Of I&CT 59

Serializability for Concurrency Control
• A serializable schedule gives the benefit of concurrency execution without giving up any
correctness
• Interleaving operations are usually executed as processes by OS and is determined by OS
scheduler by allocating resources to all processes.
• Factors such as system load, time of transaction submission, priorities of the processes
contribute to the ordering of operations in a schedule.
• Hence, difficult to decide how the operations are to be interleaved beforehand to ensure
serializability
• If transactions are executed at will, and if the effect of schedule turns out not to be serializable
then the transaction must be cancelled.
• Hence protocols or committed projections are used to enforce serializability

28 April 2025 Dept. Of I&CT 60

Broader View of
Serializability

28-Apr-25 Dept. of I&CT 61

View Equivalence and View Serializability
• Two schedules S and S’ are said to be view equivalent if the following three conditions
hold:
1. The same set of transactions participate in S and S’, and also the same set of
operations
2. For any given operation ri(X) of Ti in S, if the value of X read by the transactions, has
been written by an operation wj(X) of Tj (or if it is the original value of X before the
schedule started), the same condition must hold for the value of X read by the operation
ri(X) of Ti in S’
3. If the operation wk(Y) of Tk is the last operation to write item Y in S, then wk(Y) of
Tk must be the last operation to write item Y in S’

28 April 2025 Dept. Of I&CT 62

View Equivalent
• Two schedules S1 and S2 are said to be view equivalent if they satisfy
the following conditions:
1. Initial Read
• An initial read of both schedules must be the same. Suppose two
schedule S1 and S2. In schedule S1, if a transaction T1 is reading the
data item A, then in S2, transaction T1 should also read A.

Above two schedules are view equivalent because Initial read operation in S1 is
done by T1 and in S2 it is also done by T1.
2. Updated Read
In schedule S1, if Ti is reading A which is updated by Tj then in S2 also, Ti should
read A which is updated by Tj.

Above two schedules are not view equal because, in S1, T3 is reading A updated by
T2 and in S2, T3 is reading A updated by T1.

28-Apr-25 Dept. of I&CT 64

3. Final Write
• A final write must be the same between both the schedules. In schedule S1, if a
transaction T1 updates A at last then in S2, final writes operations should also be
done by T1.

Above two schedules is view equal because Final write operation in S1 is done by T3 and in S2, the final write
operation is also done by T3.
28-Apr-25 Dept. of I&CT 66
• A schedule S is view serializable if it is view equivalent to a serial
schedule.
• Every conflict serializable schedule is also view serializable.
• Below is a schedule which is view-serializable but not conflict
serializable.
• Every view serializable schedule that is not conflict serializable has
blind writes.
28-Apr-25 Dept. of I&CT 67
 T1 T2 T3 T1 T2 T3 T1 T2 T3

W(A) R(A) R(A)

R(A) W(A) W(A)

W(A)
W(A) W(A)
W(A)
W(A) W(A)

28-Apr-25 Dept. of I&CT 68

View Equivalence and View Serializability

• As long as each read operation of a transaction reads the result of the same
write operation in both schedules, the write operations of each transaction
must produce the same results
• A schedule S is said to be view serializable if it is view equivalent to a
serial schedule.

28 April 2025 Dept. Of I&CT 69