Chapter 17

Introduction to Transaction Processing

Concepts and Theory

Copyright © 2004 Pearson Education, Inc.

 Chapter Outline

1 Introduction to Transaction Processing

2 Transaction and System Concepts
3 Desirable Properties of Transactions
4 2PL Algorithm
5 TSO Algorithm

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-3

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 1 Introduction to Transaction Processing (1)
Database systems maybe classified according to the number of users who
can use the system concurrently.
Single-User System: At most one user can use the system at a time.
– restricted to Personal Computers
Multiuser System: Many users can access the system concurrently.
Concurrency
– Interleaved processing: concurrent execution of processes is
interleaved in a single CPU - Multiprogramming
– Parallel processing: processes are concurrently executed in
multiple CPUs.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-4

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Interleaved vs Parallel Processing
of concurrent transactions

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-5

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Introduction to Transaction Processing (2)
A Transaction: logical unit of database processing that
includes one or more access operations (read -retrieval,
write - insert or update, delete).
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.
Transaction boundaries: Begin and End transaction.
An application program may contain several
transactions separated by the Begin and End
transaction boundaries.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-6

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Introduction to Transaction Processing (3)
SIMPLE MODEL OF A DATABASE (for
purposes of discussing transactions):
A database - collection of named data items
Granularity of data – size of the data item - a field, a
record, or a whole disk block (Concepts are independent of
granularity)
Basic operations are read and write
– read_item(X): Reads a database item named X into a
program variable. To simplify our notation, we assume
that the program variable is also named X.
– write_item(X): Writes the value of program variable X
into the database item named X.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-7

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Introduction to Transaction Processing (4)

READ AND WRITE OPERATIONS:

 Basic unit of data transfer from the disk to the
computer main memory is one block. In general, a
data item (what is read or written) will be the field
of some record in the database, although it may be a
larger unit such as a record or even a whole block.
 read_item(X) command includes the following
steps:
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). The size of
the buffer is the same as the disk block size.
3. Copy item X from the buffer to the program variable named X.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-8

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Introduction to Transaction Processing (5)
READ AND WRITE OPERATIONS (cont.):
 write_item(X) command includes the
following steps:
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.
4. Store the updated block from the buffer back to
disk (either immediately or at some later point in
time).

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-9

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
The DBMS will maintain in the database cache a number of
data buffers in main memory. When these buffers are all
occupied, and additional database disk blocks must be copied into
memory, some buffer replacement policy is used to choose
which of the current occupied buffers is to be replaced. Some
commonly used buffer replacement policies are LRU (least
recently used). If the chosen buffer has been modified, it must be
written back to disk before it is reused.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-10

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Two sample transactions. (a) Transaction T1. (b) Transaction T2.

T2 – just reserves M
seats on the first
flight (X) referenced
T1 – transfers N reservations from one
flight whose number of reserved seats is in transaction T1
stored in the database item named X to
another flight whose number of reserved
seats is stored in the database item named
Y Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-11
Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Introduction to Transaction Processing (7)
Why Concurrency Control is needed: Several problems
can occur when concurrent transactions execute in an
uncontrolled manner.

Types of problems we may encounter with concurrent

transactions
a) The Lost Update Problem.
This 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.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-12

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 (a) The lost update problem.

For example, if X = 80 at the start (originally there were 80 reservations on the

flight), N = 5 (T1 transfers 5 seat reservations from the flight corresponding to X to
the flight corresponding to Y), and M = 4 (T2 reserves 4 seats on X), the final result
should be X = 79. However, in the interleaving of operations shown, it is X = 84
because the update in T1 that removed the five seats from X was lost.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-13

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Types of problems we may encounter
with concurrent transactions
b) The Temporary Update (or Dirty
Read) Problem.
This occurs when one transaction
updates a database item and then the
transaction fails for some reason. The
updated item is accessed by another
transaction before it is changed back
to its original value.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-14

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 (b) The temporary update problem.

The value of item X that is read by T2 is called dirty data because it has been
created by a transaction that has not completed and committed yet; hence, this
problem is also known as the dirty read problem.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-15
Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Types of problems we may encounter
with concurrent transactions
Why Concurrency Control is needed (cont.):
 The Incorrect Summary Problem .
If one transaction is calculating an aggregate
summary 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.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-16

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 (c) The incorrect summary problem.

T3 is calculating the total

number of reservations on all
the flights

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-17

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Types of problems we may encounter
with concurrent transactions
d) The Unrepeatable Read Problem. Another problem that
may occur is called unrepeatable read, where a transaction T
reads the same item twice and the item is changed by another
transaction T′ between the two reads. Hence, T receives different
values for its two reads of the same item. This may occur, for
example, if 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 a second time before
completing the reservation, and it may end up reading a different
value for the item.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-18

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Introduction to Transaction Processing (11)
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. 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.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-19

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Why recovery is needed
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 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.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-20

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Why recovery is needed
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

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-21

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Why recovery is needed
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.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-22

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 2 Transaction and System Concepts (1)

A transaction is an atomic unit of work that is

either completed in its entirety or not done at
all. For recovery purposes, the system needs
to keep track of when the transaction starts,
terminates, and commits or aborts.
Transaction states:
 Active state
 Partially committed state
 Committed state
 Failed state
 Terminated State

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-23

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (2)
Recovery manager keeps track of the following
operations:
 begin_transaction: This marks the beginning of
transaction execution.
 read or write: These specify read or write operations
on the database items that are executed as part of a
transaction.
 end_transaction: This specifies that read and write
transaction operations have ended and marks the end
limit of transaction execution. At this point it may be
necessary to check whether the changes introduced by
the transaction can be permanently applied to the
database or whether the transaction has to be aborted
because it violates concurrency control or for some
other reason.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-24

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (3)

Recovery manager keeps track of the following

operations (cont):
 commit_transaction: This signals a successful
end of the transaction so that any changes
(updates) executed by the transaction can be
safely committed to the database and will not be
undone.
 rollback (or abort): This signals that the
transaction has ended unsuccessfully, so that any
changes or effects that the transaction may have
applied to the database must be undone.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-25

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (4)

Recovery techniques use the following operators:

undo: Similar to rollback except that it
applies to a single operation rather than
to a whole transaction.
redo: This specifies that certain
transaction operations must be redone to
ensure that all the operations of a
committed transaction have been applied
successfully to the database.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-26

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
State transition diagram illustrating the states for
transaction execution.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-27

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (6)

The System Log

 Log or Journal : The log keeps track of all
transaction operations that affect the values of
database items. This information may be needed to
permit recovery from transaction failures. The log is
kept on disk, so it is not affected by any type of
failure except for disk or catastrophic failure. In
addition, the log is periodically backed up to archival
storage (tape) to guard against such catastrophic
failures.
 T in the following discussion refers to a unique
transaction-id that is generated automatically by
the system and is used to identify each transaction:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-28

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (7)
The System Log (cont):
Types of log record:
1. [start_transaction,T]: Records that transaction T has
started execution.
2. [write_item,T,X,old_value,new_value]: Records that
transaction T has changed the value of database item
X from old_value to new_value.
3. [read_item,T,X]: Records that transaction T has read
the value of database item X.
4. [commit,T]: Records that transaction T has completed
successfully, and affirms that its effect can be
committed (recorded permanently) to the database.
5. [abort,T]: Records that transaction T has been aborted.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-29

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (8)
The System Log (cont):
 protocols for recovery that avoid
cascading rollbacks do not require that
read operations be written to the system
log, whereas other protocols require
these entries for recovery.
 strict protocols require simpler write
entries that do not include new_value

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-30

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (9)
Recovery using log records:
If the system crashes, we can recover to a consistent
database state by examining the log and using one of
the techniques described in Chapter 19.
1. Because the log contains a record of every write
operation that changes the value of some database
item, it is possible to undo the effect of these write
operations of a transaction T by tracing backward
through the log and resetting all items changed by a
write operation of T to their old_values.
2. We can also redo the effect of the write operations of a
transaction T by tracing forward through the log and
setting all items changed by a write operation of T (that
did not get done permanently) to their new_values.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-31

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (10)

Commit Point of a Transaction:

 Definition: A transaction T reaches its commit
point when all its operations that access the
database have been executed successfully and the
effect of all the transaction operations on the
database has been recorded in the log. Beyond the
commit point, the transaction is said to be
committed, and its effect is assumed to be
permanently recorded in the database. The
transaction then writes an entry [commit,T] into the
log.
 Roll Back of transactions: Needed for transactions
that have a [start_transaction,T] entry into the log
but no commit entry [commit,T] into the log.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-32

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Transaction and System Concepts (11)
Commit Point of a Transaction (cont):
 Redoing transactions: Transactions that have written
their commit entry in the log must also have recorded all
their write operations in the log; otherwise they would
not be committed, so their effect on the database can be
redone from the log entries. (Notice that the log file must
be kept on disk. At the time of a system crash, only the
log entries that have been written back to disk are
considered in the recovery process because the contents
of main memory may be lost.)
 Force writing a log: before a transaction reaches its
commit point, any portion of the log that has not been
written to the disk yet must now be written to the disk.
This process is called force-writing the log file before
committing a transaction.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-33

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 3 Desirable Properties of Transactions (1)

ACID properties:
Atomicity: A transaction is an atomic
unit of processing; it is either performed
in its entirety or not performed at all.

Consistency preservation: A correct

execution of the transaction must take
the database from one consistent state to
another.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-34
Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Desirable Properties of Transactions (2)

ACID properties (cont.):

 Isolation: A transaction should not make its
updates visible to other transactions until it is
committed; this property, when enforced strictly,
solves the temporary update problem and makes
cascading rollbacks of transactions unnecessary
(see Chapter 21).
 Durability or permanency: Once a transaction
changes the database and the changes are
committed, these changes must never be lost
because of subsequent failure.
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-35
Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Chapter 18
Concurrency Control
Techniques

Copyright © 2004 Pearson Education, Inc.

 Chapter 18 Outline
Databases Concurrency Control
1 Purpose of Concurrency Control
2 Two-Phase locking
5 Limitations of CCMs
6 Index Locking
7 Lock Compatibility Matrix
8 Lock Granularity

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-37

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
1 Purpose of Concurrency Control

• To enforce Isolation (through mutual exclusion) among

conflicting transactions.
• To preserve database consistency through consistency
preserving execution of transactions.
• To resolve read-write and write-write conflicts.

Example: In concurrent execution environment if T1

conflicts with T2 over a data item A, then the existing
concurrency control decides if T1 or T2 should get the A
and if the other transaction is rolled-back or waits.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-38

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control

A lock is a variable associated with a data

item that describes the status of the item with
respect to possible operations that can be
applied to it. Generally, there is one lock for
each data item in the data base. Locks are
used as a means of synchronizing the access
by concurrent transactions to the database
items.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 17-39

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control

Two-Phase Locking Techniques

Locking is an operation which secures (a) permission to
Read or (b) permission to Write a data item for a transaction.
Example: Lock (X). Data item X is locked on behalf of the
requesting transaction.

Unlocking is an operation which removes these permissions

from the data item. Example: Unlock (X). Data item X is
made available to all other transactions.
Lock and Unlock are Atomic operations.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-40

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
Two locks modes (a) shared (read) and (b) exclusive (write).
Shared mode: shared lock (X). More than one transaction can apply
shared lock on X for reading its value but no write lock can be
applied on X by any other transaction.
Exclusive mode: Write lock (X). Only one write lock on X can exist
at any time and no shared lock can be applied by any other
transaction on X.
Conflict matrix
Read Write
Read

Y N
Write

N N

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-41

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
Lock Manager: Managing locks on data items.
Lock table: Lock manager uses it to store the identity of
transaction locking a data item, the data item, lock
mode and pointer to the next data item locked. One
simple way to implement a lock table is through linked
list.

Transaction ID Data item id lock mode Ptr to next data item

T1 X1 Read Next

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-42

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
Database requires that all transactions should be well-
formed. A transaction is well-formed if:

• It must lock the data item before it reads or writes

to it.
• It must not lock an already locked data item and it
must not try to unlock a free data item.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-43

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
The following code performs the lock operation:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-44

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
The following code performs the unlock operation:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-45

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The following code
performs the read operation:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-46

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The following code
performs the write lock operation:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-47

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
The following code performs the unlock operation:

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-48

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
Lock conversion
Lock upgrade: existing read lock to write lock
if Ti has a read-lock (X) and Tj has no read-lock (X) (i  j) then
convert read-lock (X) to write-lock (X)
else
force Ti to wait until Tj unlocks X

Lock downgrade: existing write lock to read lock

Ti has a write-lock (X) (*no transaction can have any lock on X*)
convert write-lock (X) to read-lock (X)

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-49

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The algorithm

Two Phases: (a) Locking (Growing) (b) Unlocking (Shrinking).

Locking (Growing) Phase: A transaction applies locks (read or write) on
desired data items one at a time.
Unlocking (Shrinking) Phase: A transaction unlocks its locked data items one
at a time.
Requirement: For a transaction these two phases must be mutually
exclusively, that is, during locking phase unlocking phase must not start and
during unlocking phase locking phase must not begin.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-50

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The algorithm

T1 T2 Result
read_lock (Y); read_lock (X); Initial values: X=20; Y=30
read_item (Y); read_item (X); Result of serial execution
unlock (Y); unlock (X); T1 followed by T2
write_lock (X); Write_lock (Y); X=50, Y=80.
read_item (X); read_item (Y); Result of serial execution
X:=X+Y; Y:=X+Y; T2 followed by T1
write_item (X); write_item (Y); X=70, Y=50
unlock (X); unlock (Y);

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-51

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The algorithm
T1 T2 Result
read_lock (Y); X=50; Y=50
read_item (Y); Nonserializable because it.
unlock (Y); violated two-phase policy.
read_lock (X);
read_item (X);
unlock (X);
Time write_lock (Y);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-52

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The algorithm

T’1 T’2
read_lock (Y); read_lock (X); T1 and T2 follow two-phase
read_item (Y); read_item (X); policy but they are subject to
write_lock (X); Write_lock (Y); deadlock, which must be
unlock (Y); unlock (X); dealt with.
read_item (X); read_item (Y);
X:=X+Y; Y:=X+Y;
write_item (X); write_item (Y);
unlock (X); unlock (Y);

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-53

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Two-Phase Locking Techniques: The algorithm

Two-phase policy generates two locking algorithms (a) Basic and (b)
Conservative.
Conservative: Prevents deadlock by locking all desired data items before
transaction begins execution.
Basic: Transaction locks data items incrementally. This may cause deadlock
which is dealt with.
Strict: A more stricter version of Basic algorithm where unlocking is
performed after a transaction terminates (commits or aborts and rolled-back).
This is the most commonly used two-phase locking algorithm.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-54

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Timestamp based concurrency control algorithm

Timestamp
A monotonically increasing variable (integer) indicating the age of an
operation or a transaction. A larger timestamp value indicates a more
recent event or operation.
Timestamp based algorithm uses timestamp to serialize the execution of
concurrent transactions.

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-55

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Timestamp based concurrency control algorithm
Basic Timestamp Ordering
1. Transaction T issues a write_item(X) operation:
a. If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an younger
transaction has already read the data item so abort and roll-back T
and reject the operation.
b. If the condition in part (a) does not exist, then execute write_item(X)
of T and set write_TS(X) to TS(T).
2. Transaction T issues a read_item(X) operation:
a. If write_TS(X) > TS(T), then an younger transaction has already
written to the data item so abort and roll-back T and reject the
operation.
b. If write_TS(X)  TS(T), then execute read_item(X) of T and set
read_TS(X) to the larger of TS(T) and the current read_TS(X).

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-56

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Timestamp based concurrency control algorithm

Strict Timestamp Ordering

1. Transaction T issues a write_item(X) operation:
a. If TS(T) > read_TS(X), then delay T until the transaction T’ that
wrote or read X has terminated (committed or aborted).
2. Transaction T issues a read_item(X) operation:
a. If TS(T) > write_TS(X), then delay T until the transaction T’ that
wrote or read X has terminated (committed or aborted).

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-57

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
 Database Concurrency Control
Timestamp based concurrency control algorithm

Thomas’s Write Rule

1. If read_TS(X) > TS(T) then abort and roll-back T and reject the
operation.
2. If write_TS(X) > TS(T), then just ignore the write operation and
continue execution. This is because the most recent writes counts
in case of two consecutive writes.
3. If the conditions given in 1 and 2 above do not occur, then
execute write_item(X) of T and set write_TS(X) to TS(T).

Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 18-58

Copyright © 2004 Ramez Elmasri and Shamkant Navathe