Module 5.

1:
Transaction Processing,
Concurrency Control, and
Schedules

Database Management Systems

 Objectives

ACID
Inconsistency Problems
State Diagram
Types of Schedules
Precedence Graph Algorithm

2
Database Management Systems
 Basic Concepts

A macro level user program is executed

to carry out a specific task within the
DBMS and this set of statements is called
as a Transaction

Micro level operations:

– Read a database object
– Write a database object into the database

3
Database Management Systems
 Sequential Vs Concurrent Execution

When transactions are strictly executed

one after the other it is termed as
sequential execution
When two or more transactions are
interleaved, then we say that it is a
concurrent execution
A A

B B

Time
4
Database Management Systems
 ACID
Atomic: Either it succeeds as a whole, or all trace of it
disappears ('all or none').
Consistent: That is, halfway through the transaction in
the database may be in an inconsistent state, but after
the execution of the transaction, the database is in a
consistent state.
Isolation: Transactions are isolated, or protected, from
the effects of concurrently scheduling other
transactions.
Durability: It survives software and hardware crashes.
Concurrency Control
- ensures Consistency and Isolation
Logging and Recovery
- ensures Atomicity and Durability
5
Database Management Systems
 Atomicity
Account A Account B
Transfer Rs. 2000
Name: John Name:
Bal: Rs. Smith
15000 1. Debit Bal: Rs.
A 500
2.
Credit B
Transactions may be incomplete for three reasons:
 Aborted
 System crash
 Terminate itself, because of read error or disk
failure
6
Database Management Systems
 Consistency

T1 T2

Account A transfer 500 Account transfer 300 Account C

Name: John B Name:
Bal: 1000 Name: Smith
1. Debit A 1. Debit Bal: 200
Smith B
2. Credit
B
Bal: 0 2. Credit
C

7
Database Management Systems
 Isolation
The isolation property is ensured by
guaranteeing that, even transactions are
executed concurrently, the net effect is
identical to serial execution.

Example: if two transactions T1 and T2

are executed concurrently, the net effect is
identical to T1 -> T2 or T2 -> T1.

8
Database Management Systems
 Durability

If a transaction is committed (written into disk) it should

persist. This property is called as durability.
The users need not worry about the incomplete
transactions.

9
Database Management Systems
 Notations

 T – Transaction
 Begin – Beginning of a transaction
 R – Read action
 W – Write action
 R(A) – Read from database object A
 W(A) – Write into database object A
 End – End of a transaction
 Commit – Store permanently
 Abort – Abort a transaction

10
Database Management Systems
 Schedule
A schedule is a set of transactions executed
either sequentially or concurrently
Schedule shows the order of execution
Example for a simple schedule:
T1 T2
R(A)
R(B)
A=A+5 Time
W(A)
B = B – 10
W(B) 11
Database Management Systems
 Read & Write ACTIONS OF A TRANSACTION

Steps involved in R(X):

– Find the address of the disk block that
contains the item X
– Copy the disk block into a buffer in main
memory
– Copy item X from the buffer to the program
variable X
Steps involved in W(X):
– Find the address of the disk block of X
– Copy the disk block into the buffer in memory
– Copy the program variable X into the buffer
– Store the updated block from buffer to disk
12
Database Management Systems
 INCONSISTENCY IN DATABASE

Lost Update Problem (RW Conflict)

The Dirty Read Problem (WR Conflict)

The Blind-Write problem (WW Conflict)

13
Database Management Systems
 1. Lost Update Problem (RW Conflict)
Assume: X = 80, N = 5, and M = 4.
Example:
T1 T2
R(X)
X=X–N
R(X)
X=X+M
W(X)
Commit
W(X)
Commit
14
Database Management Systems
 2. The Dirty Read Problem (WR Conflict)
T1 T2
A = 500 R(A)
A = 400 A = A – 100
A = 400 W(A)
R(A) A = 400
A = A * 1.06 A = 424
W(A) A = 424
R(B) B = 700
B = B * 1.06
W(B)
B = 742
B = 742
T1 → T2
Commit
B = 600 R(B)
B = 700 B = B + 100
B = 700 W(B)
Commit

T1 T2
A = 500 R(A)
A = 400 A = A – 100
A = 400 W(A)
R(A) A = 400
A = A * 1.06 A = 424
W(A) A = 424
R(B) B = 600 Interleave (T1, T2)
B = B * 1.06 B = 636
W(B) B = 636
Commit
B = 636 R(B)
B = 736 B = B + 100
B = 736 W(B)
15
Commit
Database Management Systems
 3. Blind-Write problem (WW Conflict)

A blind write occurs when a

transaction writes a value without reading it.
Example-1:

16
Database Management Systems
 3. Blind-Write problem (WW Conflict)

Example 2

17
Database Management Systems
 3. Blind-Write problem (WW Conflict)

Example 3

18
Database Management Systems
 Concurrent Transactions and Issues
5. Phantom Read Problem
• The phantom read problem happens when a transaction reads a variable once but then encounters
an error stating that the variable does not exist when it tries to read it again.

T1 T2

Read (A)

Read (A)

Delete (A)

Read (A)

Table 1

• In the example above Table 1, after transaction 2 reads the variable A, transaction 1 deletes the variable A
without the knowledge of transaction 2. As a result, when transaction 2 attempts to read A, it is unable to
do so.

19
Database Management Systems
 State diagram of a Transaction

Read/Write

End Commit

Begin PARTIALLY
PARTIALLY
ACTIVE COMMITTED COMMITTED
COMMITTED
ACTIVE COMMITTED

Abort

Abort

FAILED TERMINATED
TERMINATED
FAILED

20
Database Management Systems
 Transaction Model
The Recovery manager keeps track of the following operations…
Undo: It works in a similar way as rollback, however, it only affects a single
operation rather than the entire transaction.
Redo:
This specifies that specific transaction activities must be performed in order to
guarantee that a committed transaction's operations have been successfully
implemented in the database.
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.

Database Systems and Applications BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
21
 Why Recovery is needed?
There are several possible reasons for a transaction to fail:
– A computer failure: A hardware, software, or network error occurs in the
computer system during transaction execution.
– A transaction or system error: Some operations 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.
– Local errors or exception conditions Detected by the transaction. For
example, an insufficient account balance in a banking database may cause
a transaction, such as a fund withdrawal from that account, to be
cancelled.

Database Systems and Applications BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
22
 Why Recovery is needed?
– Concurrency control enforcement: The concurrency control method
may decide to abort the transaction. Because it violates
serializability or because several transactions are in a state of
deadlock

– Disk failure: all disks or some disk blocks may lose their data because
of a disk read/write head crash

– Physical problems: Disasters, theft, fire, etc.

Therefore, the system must keep sufficient information to recover

from the failure.

Database Systems and Applications BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
23
 Why Recovery is needed?
The System Log
The system maintains a log to keep track of all transaction operations that
affect the values of database items. This log may be needed to recover
from failures.
Types of log records :
– [start_transaction,T] : indicates that transaction T has started execution.
– [write_item,T,X,old_value,new_value] : indicates that transaction T has changed the
value of database item X from old_value to new_value. (new_value may not be
recorded)
– [read_item,T,X]: indicates that transaction T has read the value of database item X.
(read_item may not be recorded)
– [commit,T]: transaction T has been recorded permanently.
– [abort,T]: indicates that transaction T has been aborted.

Database Systems and Applications BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
24
 Types of Schedule
Complete schedule
Recoverable and Unrecoverable
schedules
Serial and Non-serial schedules
Strict schedule
Serializable schedule
Conflict equivalent schedules
Conflict serializable schedules
25
Database Management Systems
 Complete schedule
A schedule S is one which specifies
the ordering of n transactions
T1, T2, … , Tn.
T1 T2 T1 T2

R(A) R(A)
W(A) W(A)
R(B) R(B)
W(B) W(B)
Commit Commit
Commit Commit

Fig. 1 SA Fig. 2 SB

b1;
b1; r1(A);
r1(A); w1(A);
w1(A); b2;
b2; r2(B);
r2(B); w2(B);
w2(B); e1;
e1; c1;
c1; e2;
e2; c2.
c2.
26
Database Management Systems
 Recoverable and Unrecoverable Schedules

In a recoverable schedule, a committed transaction

never needs to be rolled back.
Transactions commit only after all transactions
whose changes they read commit.
T1 T2 T1 T2
R(X) R(X)
W(X) W(X)
R(X) R(X)
R(Y) W(X)
W(X) R(Y)
Commit W(Y)
Abort Commit
Commit
(a) Unrecoverable Schedule (b) Recoverable Schedule
27
Database Management Systems
 Serial and Non-serial Schedule
A schedule S is said to be serial if the
transactions involved in that schedule are
executed in a serial order
For example, if T1 and T2 are the
participating transactions in S, then T1
followed by T2 or T2 followed by T1 are
called as serial schedules
The schedules that do not follow this
consecutiveness are called as non-serial
schedules
28
Database Management Systems
 Strict Schedule
A strict schedule is one in which if a value
is written by a transaction T is not read or
overwritten by other transactions until T
either commits or aborts
Obviously, strict schedules are
recoverable and also avoid cascade abort

29
Database Management Systems
 Strict Schedule: Example
T1 T2 T1 T2
W(X)
R(X) W(X)
R(Y) Abort
Commit
W(Y)

W(X)
Commit
R(X) (b) Not a strict schedule
W(X) T2 has modified the value
of X before T1 could
Commit
commit or abort.

(a) Strict schedule 30

Database Management Systems
 Serializable Schedule
A schedule S is serializable* if it is equivalent to
some serial* schedule of the same set of
participating committed transactions in S.
Equivalences:
conflict equivalence
view equivalence

*Note: The difference between a serial and

serializable schedule is that a serial schedule is not
interleaved, but serializable schedule is interleaved.
31
Database Management Systems
 Conflict Equivalent Schedules
The two schedules are conflict
equivalent if the order of any two
conflicting operations is the same in both
schedules.
What is the meaning of Conflict?
Two operations conflict, if
– they belong to different transactions.
– they access the same data item (R / W).
– at least one is a write.

32
Database Management Systems
 Example (Non-Conflict Equivalent)
S1 S2
T1 T2 T1 T2

R(X) W(X)
W(X) R(X)

T1 reads X as 10 T1 reads X as 20
S3 S4
T1 T2 T1 T2

W(X) W(X)

W(X) W(X)

Final value of X = 30 Final value of X = 20

33
Database Management Systems
 Conflict Serializable Schedule
 A schedule is conflict
serializable if it is conflict T1 T2
equivalent to some serial W(X)
schedule.
 By rearranging the R(X)
nonconflicting operations R(Y)
r1(Y) and r2(X), as w1(X),
r1(Y), r2(X) and it can be T1 T2
made equivalent to the
serial schedule T1  T2. R(X)
Hence, this schedule is W(X)
conflict serializable.
 The second Schedule is Commit
not conflict serializable W(X)
schedule.
Commit
34
Database Management Systems
 Testing for Conflict Serializability Schedules

Algorithm Precedence_Graph()
{
Step-1: Draw nodes corresponding to each of the
transaction in S.
Step-2: Draw an edge from Ti to Tj if Ti precedes and
conflicts with Tj. Complete the
precedence graph.
(The conflicting actions are RW, WR, and WW).

Step-3: If the precedence graph is acyclic,

then print "S is conflict serializable".
else print "S is not conflict serializable".
} 35
Database Management Systems
 Example - 1
S = {b1, r1(X), w1(X), b2, r2(X), w2(X), e2, c2,
r1(Y), w1(Y), e1, c1}
r1(X) < w2(X)

T1 T2
w1(X) < r2(X)

w1(X) < w2(X)

Result: it is conflict serializable.

36
Database Management Systems
 Example - 2
S = {b2, r2(X), b1, r1(X), w1(X), r1(Y), w1(Y),
w2(X), e1, c1, e2, c2}
r2(X) <w1(X)

T1 T2
r1(X) < w2(X)

w1(X) < w2(X)

Result: it is not conflict serializable.

37
Database Management Systems
 Example - 3
S = { b2, r2(Z), r2(Y), w2(Y), b3, r3(Y), r3(Z),
b1, r1(X), w1(X), w3(Y), w3(Z), e3, c3,
r2(X), r1(Y), w1(Y), e1, c1, w2(X), e2, c2 }
X
T1 T2
Y
Z
Y
Y
T3

Result: it is not conflict serializable.

38
Database Management Systems
 Summary

39
Database Management Systems