CHAPTER 20

Introduction to Transaction
Processing Concepts and Theory

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Introduction
 Transaction
 Describes local 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

20.1 Introduction to Transaction
Processing
 Single-user DBMS
 At most one user at a time can use the system
 Example: home computer
 Multiuser DBMS
 Many users can access the system (database)
concurrently
 Example: airline reservations system

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

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- 4

Introduction to Transaction
Processing (cont’d.)
 Interleaved processing
 Parallel processing
 Processes C and D in figure below
interleaved

Parallel processing

Figure 20.1 Interleaved processing versus parallel

processing of concurrent transactions
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20-5
Transactions
 Transaction: an executing program

Forms logical unit of database processing that includes one
or more access operations:

read –retrieval

write - insert or update

delete
 Begin and end transaction statements
 Specify transaction boundaries

 A transaction (set of operations) may be stand-alone

specified in a high level language like SQL submitted
interactively, or may be embedded within a program.
 An application program may contain several
transactions separated by the Begin and End transaction
boundaries.
 Read-only transaction: no update, only retrieve db records
 Read-write transaction: all other transactions
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 6
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- 7

Read and Write Operations
 read_item(X)

Find the address of the disk block that contains item X.

Copy that disk block into a buffer in main memory (if that disk
block is not already in some main memory buffer).

Copy item X from the buffer to the program variable named X.
 write_item(X)

Find the address of the disk block that contains item X.

Copy that disk block into a buffer in main memory (if that disk
block is not already in some main memory buffer).

Copy item X from the program variable named X into its correct
location in the buffer.

Store the updated block from the buffer back to disk (either
immediately or at some later point in time).

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

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- 9

Concurrency Control – An example
 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.
 T1 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.
 T2 reserves M seats on flight X that is referenced in T1.

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

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 10
Concurrency Control
 Serial execution wastes idle CPU time
 We need to run transactions in an interleaved fashion for
better performance.
 If two or more transactions execute concurrently, some
problems may occur:

The Lost Update Problem

The Temporary Update (or Dirty Read) Problem

The Incorrect Summary Problem

The Unrepeatable Read Problem
 Concurrency Control is needed to solve these problems.

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

The Lost Update 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 item incorrect.

Figure 20.3 Some problems that occur when concurrent

execution is uncontrolled (a) The lost update problem

- Assume originally there are 80 reservations (X = 80, Y = 80), N = 5 (T 1 transfers 5 reservations

from flight X to flight Y), and M = 4 (T 2 reserves 4 seats on X), the final result should be X = 79 and
Y = 85 (if transactions are executed in the order T1, T2 or T2, T1.)
- But the scheme above sets X = 84 because the update in T 1 that removed the five seats from X
was lost.

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

The Temporary Update (Dirty Read)
Problem
• Occurs when one transaction updates a database item and
then the transaction fails for some reason.
• The system must change X back to its original value.
• The updated item X is accessed by another transaction before
it is changed back to its original value.

Figure 20.3 (cont’d.) Some problems that occur when concurrent execution is
uncontrolled (b) The temporary update problem
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20-13
The Incorrect Summary Problem
• If one transaction is calculating an aggregate sum function on a
number of records while other transactions are updating some of
these records, the aggregate function may calculate some values
before they are updated and others after they are updated.
Suppose T3 is calculating the total number of
reservations on all the flights while T1 is executing. 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.

Figure 20.3 (cont’d.) Some problems that occur when concurrent execution is uncontrolled (c)
The incorrect summary problem
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20-14
The Unrepeatable Read Problem
 Transaction T reads the same item twice
 Value is changed by another transaction T between the
two reads
 Hence, T receives different values for the two reads of the
same item
 Ex: 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 again, and it may
end up reading a different value.

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

Why Recovery is Needed
 When a transaction is submitted to database, the
system is responsible for making sure that:
 either the transaction is committed: All the
operations in the transaction are completed
successfully and their effect is recorded
permanently in the database
 or the transaction is aborted that the transaction
does not have any effect on the database or any
other transactions.

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

Types of transaction failures
1. A computer failure (system crash):
A hardware or software error occurs in the computer
system during transaction execution. If the hardware
crashes, the contents of the computer’s internal memory
may be lost.
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. In
addition, the user may interrupt the transaction during its
execution.

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

Types of transaction failures (cont’d.)
3. Local errors or exception conditions detected by the
transaction:
Certain conditions necessitate cancellation of the transaction.
For example, data for the transaction may not be found. A
condition, such as insufficient account balance in a banking
database, may cause a transaction, such as a fund withdrawal
from that account, to be canceled.
A programmed abort in the transaction causes it to fail.
4. Concurrency control enforcement:
The concurrency control method may decide to abort the
transaction, to be restarted later, because it violates
serializability or because several transactions are in a state of
deadlock (Ch 21).
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 16- 18
Types of transaction failures (cont’d.)
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:

An endless list of problems that includes power or
AC failure, fire, theft, sabotage, overwriting disks or tapes
by mistake, and mounting of a wrong tape by the operator.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 16- 19

20.2 Transaction and System
Concepts
 System must keep track of when each transaction starts,
terminates, commits, and/or aborts
 BEGIN_TRANSACTION
 READ or WRITE
 END_TRANSACTION
 COMMIT_TRANSACTION
 ROLLBACK (or ABORT)

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

Transaction and System Concepts
(cont’d.)

Figure 20.4 State transition diagram illustrating

the states for transaction execution

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

The System Log
 System log keeps track of transaction operations
 Sequential, append-only file
 Not affected by failure (except disk or
catastrophic failure)
 Log buffer
 Main memory buffer
 When full, appended to end of log file on disk
 Log file is backed up periodically
 Undo and redo operations based on log possible

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

Commit Point of a Transaction
 Occurs when all operations that access the
database have completed successfully
 And effect of operations recorded in the log
 Transaction writes a commit record into the log
 If system failure occurs, can search for
transactions with recorded start_transaction but no
commit record
 Force-writing the log buffer to disk
 Writing log buffer to disk before transaction
reaches commit point

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

DBMS-Specific Buffer Replacement
Policies
 Page replacement policy
 Selects particular buffers to be replaced when all
are full
 Domain separation (DS) method
 Each domain handles one type of disk pages

Index pages

Data file pages

Log file pages
 Number of available buffers for each domain is
predetermined

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

DBMS-Specific Buffer Replacement
Policies (cont’d.)
 Hot set method
 Useful in queries that scan a set of pages
repeatedly
 Does not replace the set in the buffers until
processing is completed
 The DBMIN method
 Predetermines the pattern of page references for
each algorithm for a particular type of database
operation

Calculates locality set using query locality set model
(QLSM)
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20- 25
20.3 Desirable Properties of
Transactions
 ACID properties
 Atomicity

Transaction performed in its entirety or not at all
 Consistency preservation

Takes database from one consistent state to
another
 Isolation

Not interfered with by other transactions
 Durability or permanency

Changes must persist in the database

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

Desirable Properties of Transactions
(cont’d.)
 Levels of isolation
 Level 0 isolation does not overwrite the dirty reads
of higher-level transactions
 Level 1 isolation has no lost updates
 Level 2 isolation has no lost updates and no dirty
reads
 Level 3 (true) isolation has repeatable reads

In addition to level 2 properties
 Snapshot isolation

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

20.4 Characterizing Schedules
Based on Recoverability
 Schedule or history
 Order of execution of operations from all
transactions
 Operations from different transactions can be
interleaved in the schedule
 Total ordering of operations in a schedule
 For any two operations in the schedule, one must
occur before the other

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

Schedules (Histories) of Transactions
 A shorthand notation for describing a schedule:
 b: begin_transaction
 r: read_item
 w: write_item
 e: end_transaction
 c: commit
 a: abort
 and append as a subscript the transaction id (transaction
number) to each operation in the schedule.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Schedules (Histories) of Transactions

 Schedule in (a) is:

Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Schedules (Histories) of Transactions

 Schedule in (b) is:

Sb: r1(X); w1(X); r2(X); w2(X); r1(Y); a1;

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Schedules (Histories) of Transactions


Two operations in a schedule 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).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Conflicting Operations in a Schedule -
Example

Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);

 In schedule Sa, the operations r1(X) and w2(X)

conflict, as do the operations r2(X) and w1(X), and the
operations w1(X) and w2(X).
 However, the operations r1(X) and r2(X) do not
conflict, since they are both read operations; the
operations w2(X) and w1(Y) do not conflict because
they operate on distinct data items X and Y; and the
operations r1(X) and w1(X) do not conflict because
they belong to the same transaction.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
More on Conflicting Schedules
 Intuitively, two operations conflict if changing their order can result in
a different outcome.
 If we change the order of the two operations r1(X); w2(X) to w2(X);
r1(X), then the value of X that is read by transaction T1 changes,
because in the second order the value of X is changed by w 2(X)
before it is read by r1(X), whereas in the first order the value is read
before it is changed. This is called a read-write conflict.
 In a write-write conflict, we change the order of two operations
such as w1(X); w2(X) to w2(X); w1(X). For a write-write conflict, the
last value of X will differ because in one case it is written by T2 and in
the other case by T1.
 Two read operations are not conflicting because changing their order
makes no difference in outcome.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Characterizing Schedules Based on
Recoverability

Schedules classified on recoverability:

1. Recoverable schedule
2. Schedules requiring cascaded rollback
3. Cascadeless schedule
4. Strict Schedules

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;

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
1. Recoverable Schedule
 Is a schedule where no transaction needs to be rolled
back.
 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.
 In addition, T’ should not have been aborted before T reads
item X, and there should be no transactions that write X
after T’ writes it and before T reads it (unless those
transactions, if any, have aborted before T reads X).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Recoverable Schedule – Example1
Sa’: r1(X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1;

 Sa’ is recoverable, even though it suffers from the lost

update problem (this problem is handled by
serializability theory)
 T2 reads X before T1 writes it. (r2(X) following r1(X), but before
w1(X)).
 Why lost update problem?

Because T2 reads X before T1 writes it.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Recoverable Schedule – Example2
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;

 Sc is not recoverable because T2 reads item X from T1, but

T2 commits before T1 commits. The problem occurs if T1
aborts after the c2 operation in Sc, then the value of X that
T2 read is no longer valid and T2 must be aborted after it is
committed, leading to a schedule that is not recoverable.
For the schedule to be recoverable, the c2 operation in Sc
must be postponed until after T1 commits, as shown in Sd:
Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Recoverable Schedule – Example2 (cont’d)

 If T1 aborts instead of committing, then T2 should also

abort as shown in Se, because the value of X T2 read is no
longer valid. In Se, aborting T2 is acceptable since it has
not committed yet.
Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

 2. Cascading Rollback (Cascading Abort)
 A schedule in which uncommitted transactions that read
an item from a failed transaction must be rolled back.
 In schedule Se, transaction T2 has to be rolled back
because it read item X from T1, and T1 then aborted.

Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

3. Cascadeless Schedule
 One where every transaction reads only the items that are
written by committed transactions.
 The 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.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

4. Strict Schedules
 A schedule in which a transaction can neither read nor
write an item X until the last transaction that wrote X has
committed (or aborted).

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

20.5 Characterizing Schedules
Based on Serializability
 Serializable schedules
 Always considered to be correct when concurrent
transactions are executing
 Places simultaneous transactions in series
 Transaction T1 before T2, or vice versa

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

 Figure 20.5 Examples of serial and nonserial schedules involving transactions T1
and T2 (a) Serial schedule A: T1 followed by T2 (b) Serial schedule B: T2 followed
by T1 (c) Two nonserial schedules C and D with interleaving of operations
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe Slide 20-44
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
in the schedule.

Otherwise, the schedule is called nonserial schedule.
 Serializable schedule:
 The type of schedules that are always considered to be correct
when concurrent transactions are executing.
 A schedule S is serializable if it is equivalent to some serial
schedule of the same n transactions.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Examples of Serial Schedules

Figure 20.5 Examples of serial and nonserial schedules involving transactions T1

and T2 (a) Serial schedule A: T1 followed by T2 (b) Serial schedule B: T2 followed
by T1 (c) Two nonserial schedules C and D with interleaving of operations

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

Examples of Nonserial Schedules

Figure 20.5 Examples of serial and nonserial schedules involving transactions T1

and T2 (a) Serial schedule A: T1 followed by T2 (b) Serial schedule B: T2 followed
by T1 (c) Two nonserial schedules C and D with interleaving of operations

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Serial and Nonserial Schedules
 One reasonable assumption we can make, if we consider the
transactions to be independent, is that every serial schedule
is considered correct.
 Serial schedules limit concurrency by prohibiting interleaving
of operations.
 We need concurrency, i.e. nonserial schedules.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Serial and Nonserial Schedules
 Assume that X = 90, Y = 90, N = 3, and M = 2 initially.
 Serial schedules A and B gives the correct results after execution as:
X = 89 and Y = 93.
 Nonserial schedule C gives the results X = 92 and Y = 93, in which
the X value is erroneous,
 Due to the lost update problem
 Nonserial schedule D gives the correct results.
Figure 20.5

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Characterizing Schedules Based on
Serializability
 Result equivalent schedules
 Produce the same final state of the database

May be accidental
 Cannot be used alone to define equivalence of
schedules

Figure 20.6 Two schedules that are result equivalent for the initial value
of X = 100 but are not result equivalent in general

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

Characterizing Schedules Based on
Serializability
 Conflict equivalent:
 Two schedules are said to be conflict equivalent if the order of any
two conflicting operations is the same in both schedules.
 If two conflicting operations are applied in different orders in two
schedules, the effect can be different.
 Scenario 1: if S1: r1(X); w2(X) and S2: w2(X); r1(X); the value read by
r1(X) can be different in the two schedules.
 Scenario 2: if S1: w1(X); w2(X) and S2: w2(X); w1(X); a next r(X)
operation will read potentially different values.
So, S1 and S2 are NOT conflict equivalent in each of the above
two scenarios.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Characterizing Schedules Based on
Serializability
 Conflict serializable:
 A schedule S is said to be conflict serializable if it is conflict
equivalent to some serial schedule S’.
 In such a case, we can reorder the nonconflicting operations in S
until we form the equivalent serial schedule S’.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

 Conflict Serializable -
Example

 D is a serializible schedule because it is equivalent to the serial

schedule A. In both schedules, the read_item(X) of T2 reads the value of
X written by T1, while the other read_item operations read the database
values from the initial database state.
 Additionally, T1 is the last transaction to write Y, and T2 is the last
transaction to write X in both schedules. Note that r1(Y) and w1(Y) of
schedule D do not conflict with r2(X) and w2(X), as they access different
data items. So, we can move r1(Y), w1(Y) before r2(X), w2(X), leading to
the equivalent serial schedule order (T1, T2)of A.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
 Conflict Nonserializable - Example

 Schedule C is not equivalent to either of the two possible serial schedules

A and B, and hence is not serializable.
 Trying to reorder the operations of schedule C to find an equivalent serial
schedule fails because r2(X) and w1(X) conflict, which means that we
cannot move r2(X) down to get the equivalent serial schedule T1, T2.
 Similarly, because w1(X) and w2(X) conflict, we cannot move w1(X) down
to get the equivalent serial schedule T2, T1.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Characterizing Schedules Based on
Serializability
 Being serializable is not the same as being serial
 Being serializable implies that the schedule is a correct
schedule.
 It will leave the database in a consistent state.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Characterizing Schedules Based on
Serializability
 Serializability is hard to check.
 Interleaving of operations occurs in an operating system through
some scheduler.
 Difficult to determine beforehand how the operations in a
schedule will be interleaved.

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Testing for Conflict Serializability

Algorithm 20.1 Testing conflict serializability of a schedule S

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe

Testing for Conflict Serializability – Example1
Figure 20.5

Figure 20.7 Constructing the precedence graphs for schedules A to D from Figure 20.5 to
test for conflict serializability (a) Precedence graph for serial schedule A (b) Precedence
graph for serial schedule B (c) Precedence graph for schedule C (not serializable) (d)
Precedence graph for schedule D (serializable, equivalent to schedule A)
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
 Testing for
Conflict
Serializability
– Example2

Figure 20.8 Another example of

serializability testing. (a) The read and write
operations of three transactions T1, T2, and
T3. (b) Schedule E. (c) Schedule F.
Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe
Testing for Conflict Serializability – Example2
(cont’d)

20.8

Copyright © 2016 Ramez Elmasri and Shamkant B. Navathe