Transaction Processing

Database Management Systems

 What is a Transaction?
• Withdrawal of Money
• Buying a product online
• Booking a Ticket online
• Fund Transfer
 Transaction
• Fund Transfer Need to Transfer
100 Rupees from
Account A to
Account B
Account A Account B
Balance - 500 Balance - 100

1. Begin Transaction
2. Read Balance (A) A transaction is an executing program
3. Compute Balance(A)-100 that forms a logical unit of database
4. Write Balance(A) processing.
5. Read Balance (B) A transaction includes one or more
6. Compute Balance(B)+100 database access operations—these can
7. Write Balance(B) include insertion, deletion, modification,
8. Commit or retrieval operations.
 Read Balance(A)
Variable XA AA 400
500
400
Read Value into XA
BB 100
200
XA = XA-100
Write XA Main Memory
Variable BA XA=500
XA=400
Read Value of B into BA
BA=BA+100 BA=200
BA=100
Write BA
Commit;

A 500
400
B 100
200
Hard Disk
 Transaction Processing Systems
• Transaction processing systems are systems
with large databases and hundreds of
concurrent users executing database
transactions.
• Examples of such systems include airline
reservations, banking, credit card processing,
online retail purchasing, stock markets,
supermarket checkouts, and many other
applications.
 Concurrent Transactions
Need to Transfer
100 Rupees from
Account A to
Account B
Account A Account B
Balance - 500 Need to Transfer Balance - 100
500 Rupees from
Account C to
Account D
Account C Account D
Balance - 1000 Balance - 2000

T1 T2
1. Begin Transaction 1. Begin Transaction
2. Read Balance (A) 2. Read Balance (C)
3. Compute Balance(A)-100 3. Compute Balance(C)-500
4. Update Balance(A) 4. Update Balance(C)
5. Read Balance (B) 5. Read Balance (D)
6. Compute Balance(B)+100 6. Compute Balance(D)+500
7. Update Balance(B) 7. Update Balance(D)
8. Commit 8. Commit
 Transaction Schedule
Time Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A)
ts3 Compute Balance(A)-100
ts4 Write Balance(A)
ts5 Read Balance (B)
ts6 Compute Balance(B)+100
ts7 Write Balance(B)
ts8 Commit
ts9 Begin Transaction
ts10 Read Balance (C)
ts11 Compute Balance(C)-500
ts12
ts13 Serial Execution Write Balance(C)
Read Balance (D)
Ts14 Compute Balance(D)+500
Ts15 of Transactions T1 Write Balance(D)
Ts16 Commit
and T2
Concurrent Execution of Transactions
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Compute Balance(A)-100
ts4 Read Balance (C)
ts5 Write Balance (A)
ts6 Compute Balance(C)-500
ts7 Read Balance (B)
ts8 Write Balance (C)
ts9 Compute Balance(B)+100
ts10 Read Balance (D)
ts11 Write Balance(B)
ts12 Compute Balance(D)+500
ts13 Commit
ts14 Write Balance(D)
ts15 Commit
Advantages of Concurrent Execution
• Waiting time of Transactions is Reduced
• Response time increases
• Resources are used effectively
 Problems with Concurrent Execution
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Compute Balance(A)-100
ts4 Read Balance (A)
A
ts5 Write Balance (A) Balance :500
ts6 Compute Balance(A)-50
ts7 Read Balance (B)
ts8 Write Balance (A) B
Balance :100
ts9 Compute Balance(B)+100
ts10 Read Balance (C)
ts11 Write Balance(B)
C
ts12 Compute Balance(C)+50 Balance : 1000
ts13 Commit
ts14 Write Balance(C)
ts15 Commit
 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.
• T2 reads the value of A before T1 changes it in
the database, and hence the updated value
resulting from T1 is lost
The Temporary Update (or Dirty Read) Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Compute Balance(A)-100
ts4 Write Balance (A) A
ts5 Read Balance (A) Balance :500
ts6 Compute Balance(A)-50
ts7 Read Balance (B)
B
ts8 Fails (ABORT)
Balance :100
ts9 Write Balance (A)
ts10 Read Balance (C)
ts12 Compute Balance(C)+50 C
Balance : 1000
ts14 Write Balance(C)
ts15 Commit
 The Temporary Update (or 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
(read) by another transaction before it is
changed back to its original value.
 The Incorrect Summary Problem
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Read Balance (A)
ts4 Compute Total = Total +
Balance (A) A
ts5 Compute Balance(A)-50 Balance :500
ts6 Read Balance (B)
ts7 Compute Total = Total +
Balance (B) B
ts8 Write Balance (A) Balance :100

ts9 Compute Balance(C)+50

ts10 Write Balance(C)
C
ts12 Read Balance (C) Balance : 1000
ts14 Compute Total = Total +
Balance (C)
ts15 Commit Commit
 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 function
may calculate some values before they are
updated and others after they are updated.
 ACID 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 preservation. A transaction should be consistency
preserving, meaning that if it is completely executed from beginning to
end without interference from other transactions, it should take the
database from one consistent state to another.
• Isolation. A transaction should appear as though it is being executed in
isolation from other transactions, even though many transactions are
executing concurrently. That is, the execution of a transaction should
not be interfered with by any other transactions executing concurrently.
• Durability or permanency. 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.
 ACID Properties
Need to Transfer
100 Rupees from
Account A to
Account B
Account A Account B
Balance - 500 Balance - 100

T1
1. Begin Transaction
2. Read Balance (A)
3. Compute Balance(A)-100
4. Update Balance(A)
5. Read Balance (B)
6. Compute Balance(B)+100
7. Update Balance(B)
8. Commit
 Concurrency Control Techniques
• Locking
Transaction uses locks to deny access to
other transactions and so prevent incorrect
updates.
Two Types of Locks
• Read_Lock(item)
• Write_Lock(item)
 Read_Lock(item)
• Read-locked item is also called share-locked
because other transactions are allowed to
read the item.
T1 REA
D_ LOC
K(B
alan
ce)
Account A
T2 READ_LOCK(Balance)
Balance : 500

B a la nce)
D _LOCK(
REA
T3
 Write_lock(item)
• If a transaction is to write an item X, it must have exclusive
access to X.
• Write-locked item is called exclusive-locked because a single
transaction exclusively holds the lock on the item.

T3 T2 REA
D _L
Wri
te_L OCK(B
OCK a
(Bal lance)
anc
e)

Account A
T1 Write_LOCK(Balance)
Balance : 500
 Unlock(item)
• After performing the operations on a item the
transaction must unlock the item so that other
transactions can use the item.
 Rules
1. A transaction T must issue the operation read_lock(X) or write_lock(X)
before any read_item(X) operation is performed in T.
2. A transaction T must issue the operation write_lock(X) before any
write_item(X) operation is performed in T.
3. A transaction T must issue the operation unlock(X) after all
read_item(X) and write_item(X) operations are completed in T
4. A transaction T will not issue a read_lock(X) operation if it already
holds a read (shared) lock or a write (exclusive) lock on item X.
5. Transaction T will not issue a write_lock(X) operation if it already holds
a read (shared) lock or write (exclusive) lock on item X.
6. A transaction T will not issue an unlock(X) operation unless it already
holds a read (shared) lock or a write (exclusive) lock on item X.
 Lost Update Problem
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Compute Balance(A)-100
ts4 Read Balance (A)
ts5 Write Balance (A)
ts6 Compute Balance(A)-50
A
ts7 Read Balance (B)
Balance :500
ts8 Write Balance (A)
ts9 Compute Balance(B)+100
ts10 Read Balance (C) B
ts11 Write Balance(B) Balance :100
ts12 Compute Balance(C)+50
ts13 Commit
C
ts14 Write Balance(C)
Balance : 1000
ts15 Commit
Preventing Loss Update Problem using Locks
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Write_Lock(A)
ts3 Read Balance (A) Begin Transaction
ts4 Write_Lock(A) – Not
allowed Because Of Lock
ts5 Compute Balance(A)-100 Wait
ts6 Write Balance (A) Wait
A
ts7 Unlock (A) Wait
Balance :500
ts8 Write_Lock(A)
ts9 READ Balance (A)
ts10 Write_LOCK(B) B
ts11 READ Balance (B) Balance :100
ts12 Compute Balance(B)+100
ts13 Compute Balance(A)-50
C
ts14 Write Balance(A)
Balance : 1000
ts15 Unlock (A)
Timestamp Transaction T1 Transaction T2
ts1 Write Balance (B)
ts2 Unlock(B)
ts3 Write_Lock(C)
ts4 Read Balance(C)
ts5 Compute Balance(C)+50
ts6 Write Balance(C)
ts7 Unlock (C) A
ts8 Commit Balance :500
ts9 Commit
ts10
B
ts11 Balance :100
ts12
ts13
ts14 C
ts15 Balance : 1000
CAN SUCH LOCKS PREVENT
TEMPORARY UPDATE PROBLEM?
The Temporary Update (or Dirty Read) Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Read Balance (A) Begin Transaction
ts3 Compute Balance(A)-100
ts4 Write Balance (A)
ts5 Read Balance (A)
ts6 Compute Balance(A)-50 A
ts9 Write Balance (A) Balance :500
ts10 Read Balance (C)
ts11 Compute Balance(C)+50
B
ts12 Write Balance(C) Balance :100

Read Balance (B)

ts13 Fails (ABORT)
C
Commit Balance : 1000
Locks for preventing The Temporary Update Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Write_LOCK(A) Begin Transaction
ts3 Read Balance (A)
ts4 Compute Balance(A)-100
ts5 Write Balance (A) Write_Lock(A) - DENIED
ts6 UNLOCK(A) Write_LOCK(A) - Granted
ts7 Read Balance (A) A
ts8 Compute Balance(A)-50 Balance :500
ts9 Write Balance (A)
Unlock(A)
Read Balance (C)
Compute Balance(C)+50 B
Balance :100
ts10 Write Balance(C)
ts11 Write_Lock(B)
Read Balance (B)
Fails (ABORT) – ROLL BACK C
Balance : 1000
ts12 Commit
The answer is 2 Phase Locking Protocol.
 Two Phase Locking Protocol
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.
 For Instance – Transfer 100 Rupees from
Account A to Account B
• Begin Transaction • Begin Transaction
• Write_Lock(A) • Write_Lock(A)
• Read_Balance(A) • Read_Balance(A)
• A=A-100 • A=A-100
• Write Balance(A) • Write Balance(A)
• Unlock(A) • Write_Lock(B)
• Write_Lock(B) • Read Balance(B)
• Read Balance(B) • B=B+100
• B=B+100 • Write Balance (B)
• Write Balance (B) • Unlock(A)
• Unlock(B) • Unlock(B)
• End Transaction • End Transaction
How it prevents Temporary Update Problem
Locks for preventing The Temporary Update Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Write_LOCK(A) Begin Transaction
ts3 Read Balance (A)
ts4 Compute Balance(A)-100
ts5 Write Balance (A) Write_Lock(A) - DENIED A
Balance :500
ts6 Write_LOCK(A) - DENIED
ts7 Write_LOCK(A) - DENIED
ts8 Write_Lock(B) Write_LOCK(A) - DENIED B
ts9 Read Balance (B) Write_LOCK(A) - DENIED Balance :100
ts10 Fails (ABORT – ROLLBACK)
UNLOCK(A) , UNLOCK(B)
ts14 Write_LOCK(A) - Granted C
ts15 Balance : 1000
Is it completely solving the problem.
Lets take another scenario
Locks for preventing The Temporary Update Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Write_LOCK(A) Begin Transaction
ts3 Read Balance (A)
ts4 Compute Balance(A)-100
ts5 Write Balance (A) Write_Lock(A) - DENIED
ts6 Write_LOCK(A) - DENIED A
ts7 Write_LOCK(A) - DENIED Balance :500
ts8 Write_Lock(B) Write_LOCK(A) - DENIED
ts9 Read Balance (B) Write_LOCK(A) - DENIED
B
ts10 B:=B+100 Balance :100
Write_Balance (B)
ts12 UNLOCK(A) Write_LOCK(A) - Granted
ts14 FAIL (ABORT)
UNLOCK(B) C
ts15 Balance : 1000
 Variations to 2 Phase Locking
• Strict 2 Phase Locking – Release the write
locks only after commit
• Rigorous 2 Phase Locking – Release all locks
only after commit
 Strict 2 PL Protocol for preventing The Temporary
Update Problem.
Timestamp Transaction T1 Transaction T2
ts1 Begin Transaction
ts2 Write_LOCK(A) Begin Transaction
ts3 Read Balance (A)
ts4 Compute Balance(A)-100 A
ts5 Write Balance (A) Write_Lock(A) - DENIED Balance :500
ts6 Write_LOCK(A) - DENIED
ts7 Write_LOCK(A) - DENIED
B
ts8 Write_Lock(B) Write_LOCK(A) - DENIED Balance :100
ts9 Read Balance (B) Write_LOCK(A) - DENIED
ts10 B:=B+100
Write_Balance (B)
C
ts12 Commit (Release Write Write_LOCK(A) - Granted
Locks) Balance : 1000
ts14
ts15
Demo on Transaction Locking
 Transaction Demo- SATISH
Satish Should transfer 100 rupees from account A to
B
• Write_lock(A)
• Update account set balance=balance-100 where
id=‘A’;
• Write_Lock(B)
• Update account set balance=balance+100 where
id=‘B’;
• Commit /Unlock A and B
 Transaction Demo- RAM
Ram Should transfer 50 rupees from account A to C
• Write_lock(A)
• Update account set balance=balance-50 where
id=‘A’;
• Write_Lock(C)
• Update account set balance=balance+50 where
id=‘C’;
• Commit /Unlock A and C
 DeadLock
• Deadlock occurs when each transaction T in a
set of two or more transactions is waiting for
some item locked by some other transaction
T’ in the set.

Timestamp Transaction 1 Transaction 2

ts1 Write_Lock(X) Write_Lock(Y)
ts2 Read (X) Read(Y)
ts3 Write_Lock(Y) Write_Lock(X)
 Dead lock Prevention
• Conservative 2 Phase Locking Protocol
• Wait-Die
• Wound -Wait
• Caution waiting
 Conservative 2 Phase Locking Protocol

• A Transaction locks all the items it needs in

advance.
• If any of the items cannot be locked then none
of the items are locked.
• The transaction waits and tries again to lock all
the items needed.
• This solution limits concurrency.
 Dead Lock Avoidance - Wait-Die
• If Transaction T1 starts before T2 then
timestamp of T1 (TS(T1)) is lesser then
timestamp of T2 (TS(T2))
• TS(T1)<TS(T2) [T1 is the older Transaction and
T2 is the younger transaction]
• Example Transaction T1 starts at 9:40 A.M and
T2 starts at 9:41 A.M. TS(T1)<TS(T2).
• T1 is the older Transaction.
 Dead Lock Avoidance - Wait-Die
• If TS(T1)<TS(T2) then T1 is requesting an item
held by T2 then
T1 is allowed to wait
The older Transaction can wait for an younger
transaction
• If T2 (Younger Transaction) requests an item
locked from T1(Older Transaction)then
T2 should Abort and restart later with the
same time stamp
 Wait-Die Algorithm
Timestamp Transaction 1 Transaction 2
(OLDER) (YOUNGER)
ts1 Write_Lock(X)
ts2 Read (X) Write_Lock(Y)
ts3 Write_Lock(Y) – Read(Y)
Wait (Older Can
Wait for Younger
Transaction)
Write_Lock(X) –
Denied (younger
cannot wait for
older) – ABORT
ts4 Write_Lock(Y) -
Granted
Dead Lock Avoidance – Wound-Wait
• If TS(T1) < TS(T2) then T1 is older than T2
and T1 requests an Item locked by T2
Abort T2 (T1 wounds T2 )
Older Transaction (T1) aborts an younger
transaction(T2) such that it the younger transaction
restarts at a later point of time with the same
timestamp.
• If T2 requests an item locked by T1 then it is
allowed to wait.
The younger transaction can wait for an older
transaction
 Wound-Wait Algorithm
Timestamp Transaction 1 Transaction 2
(OLDER) (YOUNGER)
ts1 Write_Lock(X)
ts2 Read (X) Write_Lock(Y)
ts3 Write_Lock(Y) ABORT – OLDER
Transaction T1
wounds T2
ts4 Write_Lock(Y) -
Granted
 Cautious waiting
• Cautious waiting. If Tj is not blocked (not waiting for some
other locked item), then Ti is blocked and allowed to wait;
otherwise abort Ti.
• It can be shown that cautious waiting is deadlock-free, because
no transaction will ever wait for another blocked transaction.
By considering the time b(T) at which each blocked transaction
T was blocked, if the two transactions Ti and Tj above both
become blocked and Ti is waiting for Tj, then b(Ti) < b(Tj), since
Ti can only wait for Tj at a time when Tj is not blocked itself.
Hence, the blocking times form a total ordering on all blocked
transactions, so no cycle that causes deadlock can occur.
Deadlock demo in Oracle
 Deadlock Demo
Transaction 1 Transaction 2
Write_Lock(A) Write_Lock(B)
Read Balance(A) Read Balance(B)
A:=A-100 B:=B-50
Write Balance(A) Write Balance(B)
Write_Lock(B) Write_Lock(A)
Read Balance(B) Read Balance(A)
B:=B+100 A:=A+50
Write Balance(B) Write Balance(A)
Commit – Unlock A Commit – Unlock A
and B and B