Chapter 15

Transaction Management

McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Outline
 Transaction basics
 Concurrency control
 Recovery management

15-2
Transaction Definition
 Transaction: a unit of work (collection of
database operations) that should be processed
reliably
 Supports daily operations of an organization
 DBMSs provide recovery and concurrency
control services to process transactions
efficiently and reliably so that there is no loss of
data due to multiple users and system failures

15-3
Airline Transaction Example
START TRANSACTION
Display greeting
Get reservation preferences from user
SELECT departure and return flight records
If reservation is acceptable then
UPDATE seats remaining of departure flight record
UPDATE seats remaining of return flight record
INSERT reservation record
Print ticket if requested
End If
On Error: ROLLBACK
COMMIT

15-4
ATM Transaction Example
START TRANSACTION
Display greeting
Get account number, pin, type, and amount
SELECT account number, type, and balance
If balance is sufficient then
UPDATE account by posting debit
UPDATE account by posting debit
INSERT history record
Display message and dispense cash
Print receipt if requested
End If
On Error: ROLLBACK
COMMIT
15-5
State Transition Diagram for Transaction

15-6
Transaction Properties
 Atomic: either all the work in the transaction is
completed or nothing is done
 Consistent: database must be consistent before
and after a transaction
 Isolated: no unwanted interference from other
users. A transaction should never overwrite
changes made by another transaction
 Durable: database changes are permanent after
the transaction completes

15-7
Transaction Processing
Services
 Concurrency transparency: users perceive the database
as a single-user system even though there may be many
simultaneous users
 Recovery transparency: DBMS automatically restores a
database to a consistent state after a failure
 Service characteristics
 Transparent: inner details of transaction services are invisible
 Consume significant resources eg memory, disk space to
improve performance
 Significant cost component: DBMSs that support large numbers
of concurrent users can be costly
 Transaction design is important: poor design can lead to
performance problems
15-8
Concurrency Control
 Problem definition
 Concurrency control problems
 Concurrency control tools

15-9
Concurrency Control Problem
 Objective:
 Maximize transaction throughput (work perform) while
preventing interference among multiple users
 Throughput: number of transactions processed per
unit time eg >1million transaction per second
 Constraint:
 No interference: result same as serial/sequential
effect
 Interference occurs on commonly manipulated data
known as hot spots eg seats remaining for flights,
QoH for popular inventory item, course offerings
15-10
1. Lost Update Problem
Transaction A Time Transaction B
Read SR (10) T1
T2 Read SR (10)
If SR > 0 then T3
SR = SR -1
T4 If SR > 0 then
SR = SR -1
Write SR (9) T5
T6 Write SR (9)

Lost update: a concurrency control problem in which one

user’s update overwrites another user’s update

15-11
Lost Update Problem (from Connolly)

Loss of T2’s update is avoided by preventing T1 from

reading balx until after update

15-12
2. Uncommitted Dependency Problem
Transaction A Time Transaction B
Read SR (10) T1
SR = SR - 1 T2
Write SR (9) T3
T4 Read SR (9)
ROLLBACK T5
Uncommitted dependency: a concurrency control
problem in which one transaction reads data written by
another transaction before the other transaction commits

15-13
Uncommitted Dependency Problem
(from Connolly)

Problem is avoided by preventing T3 from reading balx

until after T4 commits or aborts

15-14
3. Inconsistent Retrieval Problems
 Interference causes inconsistency among
multiple retrievals of a subset of data
 Involve one trans reading and the second
trans changing the same part of the
database
 Problems:
 Incorrect summary/Inconsistent analysis
 Phantom read/Dirty read
 Non repeatable read
15-15
3.1 Incorrect Summary Problem
Transaction A Time Transaction B
Read SR1 (10) T1
SR1 = SR1 - 1 T2
Write SR1 (9) T3
T4 Read SR1 (9)
T5 Sum = Sum + SR1
T6 Read SR2 (5)
T7 Sum = Sum + SR2
Read SR2 (5) T8
SR2 = SR2 - 1 T9
Write SR2 (4) T10

Incorrect summary/Inconsistent analysis: a trans reads

several values, but another trans updates some of the
values while the first trans is still executing

15-16
Inconsistent Analysis Problem (from
Connolly)

Problem is avoided by preventing T6 from reading balx

and balz until after T5 completed updates
15-17
3.2 Phantom Read Problem
 A trans executes a query with record
conditions but another trans inserts new
rows or modifies existing rows while the
first trans is still executing
 The first trans then reexecutes the original
query again, but the results are different
than the results for the first execution
 The new rows are phantom because they
did not exist for the first execution of the
query
15-18
3.3 Nonrepeatable Read Problem
 A trans reads the same value more than
one time
 In between reading the data item, another
transaction modifies the data item
 The second retrieval contains a different
value than the first retrieval because of the
change made by the other trans

15-19
Concurrency Control Tools
 Two basic concurrency control techniques:
 Locking
 Timestamping
 Both are conservative approaches or
pessimistic: delay transactions in case
they conflict with other transactions
 Optimistic methods assume conflict is rare
and only check for conflicts at commit

15-20
Locking Fundamentals
 Fundamental tool of concurrency control
 Obtain lock before accessing an item
 Wait if a conflicting lock is held
 Shared lock (S lock): conflicts with exclusive
locks
 Exclusive lock (X lock): conflicts with all other
kinds of locks
 Concurrency control manager maintains
the lock table
15-21
Locking Conflicts

USER 2 REQUESTS
USER 1 HOLDS S Lock X Lock
S Lock Lock Granted User 2 Waits
X Lock User 2 Waits User 2 Waits

 A shared (S) lock must be obtained before reading a

database item, whereas an exclusive (X) lock must be
obtained before writing
 Any number of users can hold a S lock on the same item
but only one user can hold X lock

15-22
Locking Granularity
Database

Table Index

Page

Row

Column
 The size of the database item locked
 A trade-off between waiting time (amount of concurrency
permitted) and overhead (number of locks held)
15-23
Deadlock (Mutual Waiting)
Transaction A Time Transaction B

XLock SR1 T1

T2 XLock SR2

XLock SR2 (wait) T3

T4 XLock SR1 (wait)

 A problem of mutual waiting that can occur when using

locks
 DBMS control deadlocks through detection or a timeout
policy
15-24
Deadlock Resolution
 Detection
 Overhead is reasonable for deadlocks among
2 or 3 transactions
 Used by enterprise DBMSs
 Timeout
 Waiting limit
 Can abort transactions that are not
deadlocked
 Timeout interval is difficult to determine
15-25
Two Phase Locking (2PL) Protocol
 Protocol to prevent lost update problems
 All transactions must follow (protocol) to
ensure that concurrency problems do not
occur
 Conditions
 Obtain lock before accessing item
 Wait if a conflicting lock is held
 Cannot obtain new locks after releasing locks

15-26
2PL Implementation
Locks held

e
has Shrinking
p
ing phase
w
G ro

Time
BOT EOT
 To provide flexibility between concurrency control
problems permitted and potential waiting, most DBMSs
relax the 2PL protocol to permit some locks to be
released before the end of a trans
15-27
Preventing Lost Update Problem
Using 2PL (from Connolly)

15-28
Preventing Uncommited Dependency
Problem Using 2PL (from Connolly)

15-29
Preventing Inconsistent Analysis
Problem Using 2PL (from Connolly)

15-30
Optimistic Approaches
 Assumes conflicts are rare
 No locks
 Concurrency control manager checks for
conflicts
 After each read and write
 Before a transaction commits
 If a conflict occurs, concurrency control
manager issues a rollback and restarts the
offending trans

15-31
Pessimistic vs Optimistic Approach
 Most organizations use 2PL even though some
enterprise DBMSs support optimistic
approaches
 The performance of optimistic approaches
depends on the frequency of conflicts. If
conflicts increase, performance decreases
 Pessimistic approaches resolve conflicts by
waiting
 Optimistic approaches resolve conflicts by rolling
back and restarting. Restarting a trans may
delay a trans more than waiting for a resource to
be released

15-32
Recovery Management
 A service/process to restore a database to
a consistent state after a failure
 This section covers:
 Device characteristics and failure types
 Recovery tools
 Recovery processes

15-33
Storage Device Basics
 Volatile: loses state after a shutdown
 Nonvolatile: retains state after a shutdown
 Nonvolatile is more reliable than volatile
but failures can cause loss of data
 DBMS may replicate data on several kinds
of nonvolatile storage media with
independent failure rates eg hard disk,
magnetic tape, optical disk to achieve high
reliability
15-34
Failure Types
 Local
 Program detected and abnormal termination
 Limited to a single transaction
 Most/Moderate frequency
 Affect the memory of executing transaction
 Operating System
 Affects all active transactions
 Less common than local failures
 Device/Media
 Affects all active and past transactions
 Least common

15-35
Recovery Tools
 Recovery manager uses redundancy and
control of the timing of database writes to
restore a database after a failure
 Forms of redundancy:
 Transaction log
 Checkpoint
 Database backup
 Forms of control timing:
 Force writing
15-36
1. Transaction Log
 History of database changes
 Recovery manager uses log table (hidden
from users) to recover from failures eg
Table 15.6
 Large storage overhead
 Operations
 Undo: revert to previous state
 Redo: reestablish a new state
 Fundamental tool of recovery mgmt
15-37
Transaction Log Example

LSN TransNo Action Time Table Row Column Old New

1 101001 START 10:29
2 101001 UPDATE 10:30 Acct 10001 AcctBal 100 200
3 101001 UPDATE 10:30 Acct 15147 AcctBal 500 400
4 101001 INSERT 10:32 Hist 25045 * <1002,
500,
…>
5 101001 COMMIT 10:33

15-38
2. Checkpoints
 Reduces restart work but adds overhead
 Checkpoint log record
 Write log buffers and database buffers to disk
 Checkpoint interval: time or size parameter
between checkpoints eg 5 minutes or number of
committed trans
 A small interval reduces restart work but cause
more overhead to record checkpoints
 Types of checkpoints
 Cache-consistent
 Fuzzy
 Incremental

15-39
3. Force Writing
 The ability of DBMS to control the timing of
write operations when data are transferred
to nonvolatile storage during
 Checkpoint time: all log and some database
buffers (temporary data storage) are force
written to disk
 End of transaction: force writes any log
records of a trans remaining in memory

15-40
4. Database Backup
 A copy of all or part of a disk
 Usually on magnetic tape due to cheap
and more reliable than disk
 To save time, backup schedules:
 Less frequent to copy the entire contents of a
disk
 More frequent to copy only the changed part

15-41
Recovery from a Media Failure
 Simple but can be time-consuming
 Restore database from the most recent
backup
 Redo all committed transactions since the
most recent backup
 Restart active transactions

15-42
Recovery for Local & System Failures
 Recovery depends on when database
changes are recorded on disk:
 Immediate update- before the commit
 Deferred update- after the commit
 The amount of work and the use of log
operations (undo & redo) depend on the
timing of database updates

15-43
Immediate Update
 Database updates are written to disk when they occur
 Occur after writes of the corresponding log records –
write ahead log protocol
 Recovery manager maintains a table of log sequence
number
 Need to redo updates of committed transactions
following a failure
 May need to undo effects of transactions that had not
committed at time of failure
 Undo operations are performed in reverse order in which
they were written to log

15-44
Deferred Update
 Database updates are written to disk only
after a trans commits
 If transaction fails before commit, it will not
have modified database and so no
undoing of changes required
 May be necessary to redo updates of
committed transactions as their effect may
not have reached database

15-45
Recovery Timeline
Checkpoint Failure

Time

T1

T2

T3

T4

T5

15-46
Immediate Update Recovery
Class Description Restart Work
T1 Finished before CP None
T2 Started before CP; Redo forward from
finished before failure checkpoint
T3 Started after CP; Redo forward from
finished before failure checkpoint
T4 Started before CP; not Undo backwards
yet finished from most recent log
record
T5 Started after CP; not Undo backwards
yet finished from most recent log
record

15-47
Deferred Update Recovery
Class Description Restart Work
T1 Finished before CP None
T2 Started before CP; Redo forward from
finished before failure first log record
T3 Started after CP; Redo forward from
finished before failure first log record
T4 Started before CP; not None
yet finished
T5 Started after CP; not None
yet finished

15-48
Oracle 10g Recovery Features
 Incremental checkpoints
 Immediate update approach
 Mean Time to Recover (MTTR) parameter
 MTTR advisor
 Dynamic dictionary views to monitor
recovery state

15-49
Summary
 Transaction: user-defined collection of work
 DBMSs support ACID properties
 Knowledge of concurrency control and recovery
important for managing databases
 Transaction design issues are important
 Transaction processing is an important part of
workflow management

15-50
Review Questions
Final Exam April 2010 Question 5
a. MyShop Department Store runs a multiuser
DBMS. Unfortunately, at the present time, the
DBMS does not enforce concurrency control.
One MyShop customer had a initial balance of
RM250.00 when the following three
transactions related to this customer were
processed at about the same time:
 Payment of RM250.00
 Purchase on credit of RM100.00
 Merchandise return (credit) of RM50.00
 The updated customer record was then returned to
the database.
15-51
Review Questions
i. What will the customer’s balance be after the three transactions
have been processed?
(3 marks)
ii. What should the customer‘s balance be, if concurrency control is
enforced?
(3 marks)
iii State the problem encountered in the above scenario.
(2 marks)
iv. Explain the difference between serial and concurrent
transactions.
(4 marks)
v. ‘Unfortunately, at the present time, the DBMS does not enforce
concurrency control’. Give your understanding of this statement.
How can the DBMS enforce concurrency control?
(6 marks)

15-52
Review Questions
b. Name any transaction that allows
concurrent access to the UiTM Student
Information System (ISIS) database.
(2 marks)

 Answer

15-53
Review Questions
 Final Exam Oct 2009 Question 4
a) i. Describe with an example the lost update problem.
(6 marks)
ii. Use your example in (ii) to show how the Two-Phase
Locking protocol can prevent this type of problem.
(4 marks)
b) Consider the case of immediate database approach
and assume that, after a crash, the log contains the
following records:

15-54
Review Questions
i. Which transaction(s) will Transaction Object Old New
be redone during Value Value
recovery? T1 (starts)
(4 marks) T1 J 400 500
ii. Which transaction(s) will T1 K 300 400
be undone during T1( commits)
recovery?
T2 (starts)
(4 marks)
T2 L 100 200
ii. What will be the value of
T3 (starts)
data item ‘J’, and ‘N’ after
the recovery? T3 M 700 800

(2 marks) T3 (commits)
T4 (starts)
 Answer
T4 N 800 900
15-55