UCCD2303 DATABASE TECHNOLOGY /

UCCD2203 DATABASE SYSTEMS

Lecture 5
by
Ts. Dr. Chan Lee Kwun & Mr. Cheang Kah Wai
Department of Information Systems, FICT
 Lecture 5 Topic: Transaction
Management - Part 1

 Introduction to Transaction Management

Concepts and Theory
 Concurrency Control Techniques
Transaction

A transaction is a logical unit of work

on the database.
 It may be an entire program or a part
of a program, or a single SQL
statement, and it may involve any
number of operations on the database.
Transaction Support

 Action, or series of actions (Read and Write),

carried out by user or application, which
accesses or changes the contents of
database.

 Transforms database from one consistent

state to another, although consistency may
be violated during transaction.
Example - Transaction
Transaction Support
 Can have one of two outcomes:
 Committed - transaction commits and database
reaches a new consistent state.
 Aborted - transaction aborts, and database must be
restored to consistent state before it started.
 Such a transaction is rolled back or undone.

 Committed transaction cannot be aborted.

 Aborted transaction is rolled back and can be
restarted later.
State Transition Diagram for Transaction

In addition to the obvious states of ACTIVE, COMMITTED

and ABORTED, there are other two states:
 PARTIALLY COMMITTED, FAILED
Properties of Transactions
Four basic Atomicity, Consistency, Isolation, and Durability
(ACID) properties properties of a transaction are:
Atomicity 'All or nothing' property.
Consistency Must transform database from one
consistent state to another (data integrity).
Isolation Partial effects of incomplete transactions
should not be visible to other transactions.
Durability Effects of a committed transaction are
permanent and must not be lost because
of later failure.
Concurrency Control
 Although two transactions may be correct in
themselves, interleaving of operations may
produce an incorrect result.
 Process of managing simultaneous operations
on the database without having them interfere
with one another.
 Prevents interference when two or more users
are accessing database simultaneously and at least
one is updating data.
 Need for Concurrency Control
 Three examples of potential problems caused by
concurrency in multiuser environments:
 Lost update problem

 Uncommitted dependency problem

 Inconsistent analysis problem

 Coordinates simultaneous transaction execution

in multiprocessing database
 Ensure serializability of transactions in
multiuser database environment.
Lost Update Problem
 A successfully completed update operation by
one user can be overridden by another user.
Lost Update Problem - example
 T1 withdrawing $10 from an account with
balx, initially $100.
 T2 depositing $100 into same account.

 Serially, final balance would be $190.

 Loss of T2's update is avoided by

preventing T1 from reading balx until
after update.
Uncommitted Dependency (or dirty read) Problem
 This occurs when one transaction is allowed to
see the intermediate results of another
transaction before it has committed.
Uncommitted Dependency Problem
 T4 updates balx to $200 but it aborts,
so balx should be back at original value of
$100.
 T3 has read new value of balx ($200)
and uses value as basis of $10 reduction,
giving a new balance of $190, instead of
$90.
 Problem is avoided by preventing T3 from reading
balx until after T4 commits or aborts.
 Inconsistency analysis problem
 The two problems concentrated on transactions
that are updating the database and their
interference may corrupt the database.
 However, transactions that only read the database
can also produce inaccurate results if they are
allowed to read partial results of incomplete
transactions that are simultaneously updating the
database.
The inconsistency analysis problem
Inconsistent Analysis (fuzzy read or nonrepeatable read)
Problem
 Occurs when transaction reads several values but
second transaction updates some of them during
execution of the first.
Inconsistent Analysis Problem
 T6 is totaling balances of account x
($100), account y ($50), and account z
($25).
 Meantime, T5 has transferred $10 from
balx to balz, so T6 now has wrong result
($10 too high).
 Problem is avoided by preventing T6 from
reading balx and balz until after T5 completed
updates.
Read/Write Conflict Scenarios:

Conflicting Database Operations Matrix

Serializability
 Objective of a concurrency control
protocol is to schedule transactions in
such a way as to avoid any interference.
 Could run transactions serially, but this
limits the degree of concurrency or
parallelism in system.
 Serializability identifies those executions
of transactions guaranteed to ensure
consistency.
Serializability
Schedule
A sequence of reads/writes by set of concurrent
transactions that preserves the order of the
operations in each of the individual transactions
Serial Schedule
Schedule where operations of each transaction are
executed consecutively without any interleaved
operations from other transactions.
 No guarantee that results of all serial executions of a
given set of transactions will be identical.
Nonserial Schedule
 Schedule where operations from set of
concurrent transactions are interleaved.
 Objective of serializability is to find nonserial
schedules that allow transactions to
execute concurrently without interfering with
one another.
 In other words, we want to find nonserial
schedules that are equivalent to some serial
schedule. Such a schedule is called
serializable.
Serializability
In serializability, ordering of read/writes is
important:
(a) If two transactions only read a data item,
they do not conflict and order is not
important.
(b) If two transactions either read or write
completely separate data items, they do not
conflict and order is not important.
(c) If one transaction writes a data item and
another reads or writes same data item,
order of execution is important.
Conflict Serializability
 Conflict serializable schedule orders any
conflicting operations in same way as
some serial execution.
 Under constrained write rule (transaction
updates a data item based on its old value,
which is first read by the transaction), we
can use precedence graph to test for
serializability.
Precedence Graph
 Create a node for each transaction;
 a directed edge T1  T2, if T2 reads the value
of an item written by T1;
 a directed edge T1  T2, if T2 writes a value
into an item after it has been read by T1.
 a directed edge T1  T2, if T2 writes a value
into an item after it has been written by T1.
 If precedence graph contains cycle, the schedule
is not conflict serializable.
Example - Non-conflict serializable schedule

 T9 is transferring 100 from one account

with balance balx to another account with
balance baly.
 T10 is increasing balance of these two
accounts by 10%.
 Precedence graph has a cycle and so is
not serializable.
Example - Non-conflict serializable schedule
T9 is transferring 100 from one account with balance baly to
another account with balance balx.
T10 is increasing balance of these two accounts by 10%.
Example - Non-conflict serializable schedule

Precedence graph for

Transactions T9 and T10
showing a cycle, so
schedule is not conflict
serializable.
View Serializability
 Offers less stringent definition of schedule
equivalence than conflict serializability.

 Two schedules S1 and S2 are view equivalent if the

following three conditions hold:
 For each data item x, if Ti reads initial value of x in S1, Ti
must also read initial value of x in S2.
 For each read on x by Ti in S1, if value read by x is
written by Tj, Ti must also read value of x produced by Tj
in S2.
 For each data item x, if last write on x performed by Ti in
S1, same transaction must perform final write on x in S2.
View Serializability
 Schedule is view serializable if it is view
equivalent to a serial schedule.
 Every conflict serializable schedule is
view serializable, although converse is not
true.
 It can be shown that any view serializable
schedule that is not conflict serializable
contains one or more blind writes.
Example - View Serializable schedule
Not conflict serializable

Precedence graph for

view serializable
schedule.
Concurrency Control Techniques
 Two basic concurrency control techniques:
 Locking
 Timestamping
 Both are conservative (pessimistic)
approaches: delay transactions in case they
conflict with other transactions.
 Optimistic methods assume conflict is rare
and only check for conflicts at commit.
Locking
Transaction uses locks to deny access to other
transactions and so prevent incorrect updates.
 Most widely used approach to ensure
serializability.
 Generally, a transaction must claim a shared (read)
or exclusive (write) lock on a data item before read
or write.
 Lock prevents another transaction from modifying
item or even reading it, in the case of a write lock.
Lock Modes

 Two main lock modes:

 Binary locks
 Shared locks/Exclusive locks
Locking - Basic Rules
 If transaction has shared lock on item,
can read but not update item.
 If transaction has exclusive lock on item,
can both read and update item.
 Reads cannot conflict, so more than one
transaction can hold shared locks
simultaneously on same item.
 Exclusive lock gives transaction exclusive
access to that item.
Concurrency Control-with Locking Methods
 Lock guarantees current transaction exclusive
use of data item
 Acquires lock prior to access
 Lock released when transaction is completed
 DBMS automatically initiates and enforces
locking procedures
 Managed by lock manager
 Lock granularity indicates level of lock use –
database, table, page, row, or field lock levels
Database-Level Locking Sequence
Table-Level Lock
Example - Incorrect Locking Schedule

 For two transactions above, a schedule using these

rules is:

S = {write_lock(T9, balx), read(T9, balx), write(T9,

balx), unlock(T9, balx), write_lock(T10, balx),
read(T10, balx), write(T10, balx), unlock(T10, balx),
write_lock(T10, baly), read(T10, baly), write(T10,
baly), unlock(T10, baly), commit(T10), write_lock(T9,
baly), read(T9, baly), write(T9, baly), unlock(T9, baly),
commit(T9) }
Example - Incorrect Locking Schedule
 If at start, balx = 100, baly = 400, result should be:

 balx = 220, baly = 330, if T9 executes before T10;

or
 balx = 210, baly = 340, if T10 executes before T9.

 However, result of executing S gives balx = 220 and

baly = 340.
 S is not a serializable schedule.
Does not guarantee serializability.
Example - Incorrect Locking Schedule

 Problem is that transactions release locks

too soon, resulting in loss of total
isolation and atomicity.
 To guarantee serializability, need an
additional protocol concerning the
positioning of lock and unlock operations
in every transaction.
Two-Phase Locking (2PL)
Transaction follows 2PL protocol if all
locking operations precede first unlock
operation in the transaction.

 Two phases for transaction:

 Growing phase - acquires all locks but
cannot release any locks.
 Shrinking phase - releases locks but
cannot acquire any new locks.
Lost Update Problem
Preventing Lost Update Problem using 2PL
Deadlock
An impasse that may result when two (or more)
transactions are each waiting for locks held by the
other to be released.
Deadlock
 Only one way to break deadlock: abort one
or more of the transactions.
 Deadlock should be transparent to user, so
DBMS should restart transaction(s).
 Three general techniques for handling
deadlock:
 Timeouts.

 Deadlock prevention.

 Deadlock detection and recovery.

Deadlock Prevention
 DBMS looks ahead to see if transaction
would cause deadlock and never allows
deadlock to occur.
 Could order transactions using transaction
timestamps:
 Wait-Die - only an older transaction can wait for
younger one, otherwise transaction is aborted
(dies) and restarted with same timestamp.
Eventually, it will become the oldest active
transaction and will not die.
Deadlock Prevention

 Wound-Wait - only a younger

transaction can wait for an older one.
If older transaction requests lock held by
younger one, younger one is aborted
(wounded).
Deadlock Detection and Recovery
 DBMS allows deadlock to occur but
recognizes it and breaks it.
 Usually handled by construction of wait-for
graph (WFG) showing transaction
dependencies:
 Create a node for each transaction.

 Create edge Ti -> Tj, if Ti waiting to lock

item locked by Tj.
 Deadlock exists if and only if WFG contains
cycle.
 WFG is created at regular intervals.
Example - Wait-For-Graph (WFG)
Produce a wait-for-graph for the following transaction
scenario and determine whether deadlock exists.
• Create a node for each transaction.
• Create edge Ti -> Tj, if Ti waiting to lock item
locked by Tj.
Timestamping
 Transactions ordered globally so that
older transactions, transactions with
smaller timestamps, get priority in the
event of conflict.
 Conflict is resolved by rolling back
and restarting transaction.
 No locks so no deadlock.
Timestamping
Timestamp
A unique identifier created by DBMS
that indicates relative starting time of a
transaction.

 Can be generated by using system clock

at time transaction started, or by
incrementing a logical counter every time
a new transaction starts.
Timestamping
 Read/write proceeds only if last update on that
data item was carried out by an older transaction.
 Otherwise, transaction requesting read/write is
restarted and given a new timestamp.
 Also timestamps for data items:
 read-timestamp - timestamp of last
transaction to read item.
 write-timestamp - timestamp of last
transaction to write item.
The End Of Lecture 5
Thank You