CHAPTER - 3

CONCEPTS OF TRANSACTION AND

TRANSACTION PROCESSING SYSTEM

1
 Objectives of the Chapter

At the end of the chapter 3 : the student able to understand :-

 Introduction to Transaction

 Transaction and System Concepts

 Properties of Transaction

 Concurrency Control, Schedules

 Serializability of Schedules

2
Transaction

3
 What is a Transaction?
 An atomic unit of Database access, which is either completely executed or not executed at

all.

 A transaction is a unit of program under execution that accesses and possibly updates various

data items.

 Transaction also logical unit of database processing that includes one or more access

operations (read –retrieval, write - insert or update, delete).

 Example of Transaction: ATM transaction, Airline reservations, Banking, Hotel check-in,

Credit card processing, Supermarket scanning, Academic registration, Billing and many other
4
applications.
 Cont’d
 If the database operations in a transaction do not update the database but only retrieve data, the

transaction is called a read-only transaction; otherwise it is known as a read-write transaction.

 A transaction can have one of two outcomes:

 Committed: If a transaction completed successfully and the database reaches a new

consistent state.

 Aborted: If the transaction does not execute successfully. The database must be restored

to the consistent state it was before the transaction started. Such a transaction is called

rolled back or undone.

5
 Cont’d
 A successful transaction changes the database from one consistent state to another.

 A consistent database state is one in which all data integrity constraints are satisfied.

 To ensure consistency of the database, every transaction must begin with the database in a

known consistent state and end in a consistent state.

 For recovery purpose ,the system needs to keep track of when the transaction starts,

terminates and commits or aborts.

 Transaction Boundaries: any single transaction in application program is bounded with

Begin and End statements.

6
 Cont’d
 Basic operations that a transaction can perform are read and write.

 Read-item(X): Reads a database item named X into a program variable.

 Write-item(X): Write the value of program variable X into the database item named X.

 E.g. transaction to transfer 50 from account A to account B:

1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
7
 Transaction States
 Active state:- Indicates the beginning of transaction execution.

 Partially committed state:- shows the end of read/write operation but this will not ensure

permanent modification on the database.

 Committed state:- ensure that all the changes done on a record by a transaction were done

persistently.

 Failed state:- happens when transaction is aborted during its active state or if one of the

rechecking is fails.

 Terminated State:- corresponds to the transaction leaving the system.

8
State Transaction Diagram

9
 Transaction ACID Properties
 To ensure data integrity, data consistency, DBMS should maintain the following ACID
properties:

Atomicity
 Atomicity - is atomic unit of processing, it is either performed in its entirely or not

performed at all.

 “All or Nothing”

 If the transaction execute complete

// done

Else aborted 10
 Cont’d
Example:

 Transfer of amount 750 birr from account A to account B. Before execution of transaction

account A= 5000 birr and Account B= 8000 birr any failure (power failure, disk failure, hardware

error..)

 The failure occurs after complete of write(A) operation but before the execution of write (B)

operation.

 Account A is loss amount of 750 due to failure.

 Now the database is inconsistent state.

 To have consistency data the DBMS have a capability of restore to the old value. 11
 Consistency
 A correct execution of the transaction must take the database from one consistent state to another.

 No violation of integrity constraint.

 It is constant before and after the transaction.

 From the above example before transaction, transaction account A= 5000 birr and Account B=

8000 birr.

 After execution complete Account A=4250 and Account B=8750 that means equivalent with

13000 before and after.

 Now the database is consistent state.

12
 Isolation
 Isolation properties is particularly useful when there are concurrent transaction (a number of user

concurrently access the shared data in the database at the same time)

 The data used during the execution of one transaction can not be used by any other transaction until

the one using it had completed.

 They do not interfere with each other.

 suppose two transaction T1 and T2 executing concurrently.

 T1 transfer amount 750$ from account A to B.

 T2 transfer 20% of amount from account A to B.

 Suppose account A =5000$ and account B= 8000$ 13

 Cont’d
 Schedule 1 Consistent state

T1 T2 Description
Read(A) 5000$
A=A-750$ 4250$
Write(A) Store to A
Read(A) 4250$
Temp=A*0.2 850$
A=A-Temp 3400$
Write(A) Store to A
Read(B) 8000$
B=B+750$ 8750$
Write(B) Store to B
Read(B) 8750$
B=B+ Temp 9600$
Write(B) Store to B
 Cont’d
 Schedule 2 Inconsistent state

T1 T2 Description
Read(A) 5000$
A=A-750$ 4250$
Read(A) 5000$
Temp=A*0.2 1000$
A=A-Temp 4000$
Write(A) Store to A=4000$
Read(B)
Write(A) 4250$
Read(B) 8000$
B=B+750$ 8750$ 4000$+9750$=13750$
Write(B) Store to B=8750$ So the transaction lost 750$
It leads to inconsistence
B=B+ Temp 9750$
Write(B) Store to B=9750$
 Durability
 Once a transaction changes the database and the changes are committed, these changes must never

be lost because of subsequent failure.

 It ensures that once transaction changes are done (committed), they cannot be undone or lost.
 Durability is the responsibility of the recovery subsystem of the DBMS.
EXAMPLE
 T1 is transfer 1000 birr from account X(which is 10,000 birr) to Y(which is 20,000 birr)as follows
Read(X) Atomicity:- All done or None
X=X-1000 Consistency:- Before C+B= After C+B
Write(X) Isolation:- never interference by other transaction
Read(Y) Durability:- committed transaction never rollback or failed
Y=Y+1000
Write(Y)
16
 Transaction Processing Systems

 Transaction processing systems:- systems with large databases and many of concurrent users

executing database transactions.

Eg. airline reservations, banking, credit card processing, online retail purchasing and many

other applications

 A DBMS is single-user if at most one user at a time can use the system, and it is multiuser if

many users can use the system.

 DBMS with multiple users must have the ability to support concurrent operations.

17
 Cont’d
 According to the number of users who can use the system concurrently a DBMS is classified

into two.

1. Single-User : A DBMS is single-user if at most one user at a time can use the system.

2. Multiuser: if many users can use the system and accesses the database concurrently.

 Database systems used in banks, insurance agencies, stock exchanges, supermarkets, and many

other applications are multiuser systems.

 In these systems, hundreds or thousands of users are typically operating on the data-base by

submitting transactions concurrently to the system.

18
 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)

2. A transaction or system error

3. Local errors or exception conditions detected by the transaction

4. Concurrency Control Enforcement

5. Disk failure

6. Physical problems and catastrophes 19

 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.

 In the first case, the transaction is said to be committed, whereas in the second case, the

transaction is aborted.

 Database recovery restores a database from a given state (usually inconsistent) to a

previously consistent state after a failure.

20
 Transaction Log
 The transaction log is a critical part of the database and it is usually implemented as one or

more files that are managed separately from the actual database files.

 The transaction log is subject to common dangers such as disk-full conditions and disk

crashes.

 A DBMS uses a transaction log to keep track of all transactions that update the database.

 The information stored in this log is used by the DBMS for a recovery requirement triggered

by a rollback statement, a program’s abnormal termination, or a system failure.

 Although using a transaction log increases the processing overhead of a DBMS, the ability to
21
 Cont’d
 While the DBMS executes transactions that modify the database, it also automatically updates the

transaction log. The transaction log stores:

1. A record for the beginning of the transaction.

2. For each transaction component (SQL statement):

a. The types of operation being performed (update, delete, insert).

b. The names of the objects affected by the transaction (the name of the table).

c. The “before” and “after” values for the fields being updated.

d. Pointers to the previous and next transaction log entries for the same transaction.
22
Concurrency Control

23
 Concurrency Control
 When two or more users are accessing the database simultaneously and at least one is updating

data, there may be interference that can result in inconsistencies.

 Concurrency control is the process of managing simultaneous operations on the database without

having them interfere with one another.

Why Concurrency Control is needed?

 A major objective in developing a database is to enable many users to access shared data

concurrently (execute multiple transaction at a time).

 The objective of concurrency control is to ensure the serializability of transactions in a multiuser

24
Problems of Concurrent Sharing

25
 Problems of Concurrent Sharing
 The simultaneous execution of transactions over a shared database can create several data

integrity and consistency problems.

 Concurrent access of database case problem during writing rather than read operation.

 The three main problems are lost updates, uncommitted data, and inconsistent retrieval.

1. Lost Update (WW Conflict)

 The lost update problem occurs when two concurrent transactions, T1 and T2, are updating

the same data element and one of the updates is lost (overwritten by the other transaction.)
26
 Example
 Some problem that occur current execution is uncontrolled Suppose account A =1000

 Transactions are as below:

seqno T1 T2
1 Read(A)
2 A=A+100

Read(A)
3
4
A=A-200
5
-no Write(A)1100

6 Write(A)800

Transactions Not Execute Serially

 Example
 Assume that you have a product whose current quantity value is 35. Also assume that two

concurrent transactions, T1 and T2, occur that update the quantity value for some item in the

database. The transactions are as below:

28
 Cont’d

 Following table shows the serial execution of those transactions under

normal circumstances, yielding the correct answer quantity = 105.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
5 T2 quantity =135-30
6 T2 Write quantity 105
 Cont’d
 The sequence depicted below shows how the lost update problem can arise.
 Note that the first transaction (T1) has not yet been committed when the second
transaction (T2) is executed.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T2 Read quantity 35
3 T1 quantity =35 +100
4 T2 quantity =35-30
5 T1 Write quantity 135
6 T2 Write quantity 5 (Lost update)
 2. Uncommitted Data (The Temporary Update (or
“Dirty Read”, WR) Problem)
 Uncommitted data occurs when two transactions, T1 and T2, are executed concurrently and the

first transaction (T1) is rolled back after the second transaction (T2) has already accessed the

uncommitted data.

 Example: let’s use the same transactions described during the lost updates discussion. T1 is

forced to roll back due to an error. T1 transaction is rolled back to eliminate the addition of the

100 units. Because T2 subtracts 30 from the original 35 units, the correct answer should be 5.

31
 Example

 Following table shows the serial execution of those transactions under

normal circumstances, yielding the correct answer quantity = 5.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T1 Rollback 35
5 T2 Read quantity 35
6 T2 quantity =35-30
7 T2 Write quantity 5
 Cont’d

 Following table shows how the uncommitted data problem can arise when
the ROLLBACK is completed after T2 has begun its execution.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
(Reading uncommitted data)
5 T2 quantity =135-30
6 T1 ROLLBACK 35
7 T2 Write quantity 105
 3. Inconsistent Retrievals (The Incorrect Summary
Problem)
 Inconsistent retrievals occur when a transaction accesses data before and after another

transaction(s) finish working with such data.

 For example, an inconsistent retrieval would occur if transaction T1 calculated some summary

(aggregate) function over a set of data while another transaction (T2) was updating the same data.

 The problem is that the transaction might read some data before they are changed and other data

after they are changed, thereby yielding inconsistent results.

34
 Example
 T1 would like to add the values of A =100, B=200, C=300
 After the values are read by T1 and before its completion, T2 update the value of
B=500.At the end of execution of two transaction T1 will come up with the sum of 600,
While it should be 900 since B is updated to 500.

T1 T2
Sum=0;
Read_item(A)
Sum=Sum+A
Read_item(B)
Sum=Sum+B
-no Read_item(B)
B=50

Read_item(C)
Sum=Sum+C
 Example
 To illustrate that problem, assume the following conditions:

1. T1 calculates the total quantity of products stored in the PRODUCT table.

2. At the same time, T2 updates the quantity for two of the items in the PRODUCT
table.

 The two transactions are shown as:

Transaction 1 Transaction 2
Select sum(quantity) from product; Update product set quantity=quantity+10 where pid =
1003
Update product set quantity =quantity-10 where pid=1004
Commit
 Cont’d

 The following table shows the serial execution of those transactions

under normal circumstances

Product_id (pid) Before update After Update

1001 8 8
1002 32 32
1003 15 25(15+10)
1004 23 13(23-10)
1005 8 8
Total 86 86
 Cont’d
• Below Table demonstrates that inconsistent retrievals are possible during the transaction
execution, making the result of T1’s execution incorrect.
Time Transaction Action Value Total
1 T1 Read quantity for pid=1001 8 8
2 T1 Read quantity for pid=1002 32 40
3 T2 Read quantity for pid=1003 15
4 T2 Quantity=qunatity+10
5 T2 Write quantity for pid=1003 25
6 T1 Read quantity for pid=1003 25 65
7 T1 Read quantity for pid=1004 23 88
8 T2 Read quantity for pid=1004 23
9 T2 Quantity=qunatity-10
10 T2 Write quantity for pid=1004 13
11 T2 Commit
12 T1 Read quantity for pid=1005 8 96
 4. The Unrepeatable Read Problem

 A transaction T1 reads the same item twice and the item is changed by another transaction T2

between the two reads. Hence, T1 receives different values for its two reads of the same item.

 For example, during an airline reservation transaction, a customer inquiry 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.

39
Characterizing of Schedules Based on Recoverability and
Serializability

40
 Concepts of Schedule
 Schedule: – it is a sequence of instructions that specify the chronological order in which

instructions of concurrent transactions are executed.

 A schedule for a set of transactions must consist of all instructions of those transactions.

 The scheduler is a special DBMS process that establishes the order in which the operations

within concurrent transactions are executed.

 The scheduler interleaves the execution of database operations to ensure serializability and

isolation of transactions.
41
 Cont’d
 To determine the appropriate order, the scheduler bases its actions on concurrency control

algorithms, such as locking or time stamping methods.

 Additionally, the scheduler facilitates data isolation to ensure that two transactions do not update

the same data element at the same time.

 Two operations are said to conflict if they:

1. Belong to different transactions

2. Access the same database item and

3. At least one of the two operations is a write operation.

42
 Cont’d

Transactions T1 T2 Result
Read (x) Read (x) No conflict
Read (x) Write (x) Conflict
Operations
Write (x) Read (x) Conflict
Write (x) Write (x) Conflict
 Cont’d

T1 T2 T1 T2
Read (x) Read (x)
S1 S2
Read (x) Write(x)

No conflict Conflict

T1 T2
Write (x)
S3
Write (x)

Conflict
Characterizing of Schedules Based on Recoverability

45
 Characterizing Schedules Based on Recoverability

 Once a transaction is committed, it should never be necessary to roll back => durability
property.

The schedules that theoretically meet this criterion are called recoverable schedules;
those that do not are called non recoverable.

 Recoverable Schedule – Should be permitted by DBMS

 Non recoverable Schedule – Should not be permitted

 Recoverable Schedule

No committed transaction needs to be rolled back.

 A schedule S is recoverable if no transaction Tj in S commits until all transaction Ti that

have written an item that Tj reads have committed.

Example(Identify the following schedules as Recoverable/Non recoverable)

Sa: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;

Sb: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;

Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2;
Sd: r1(x); r2(z); r1(z); r3(x); r3(y); w1(x); c1; w3(y); c3; r2(y); w2(z); w2(y);c2
Se: r1(x); r2(z); r1(z); r3(x); r3(y); w1(x); c1; w3(y); a3; r2(y); w2(z); w2(y);c2
 Cont’d

Sa : r1 (X); r2(X); w1(X); r1(Y); w2(X); c2; Recoverable (but suffers from lost update
w1(Y); c1; problem)

Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; Non recoverable

a 1; T2 reads x from T1, and then T2 commits before T1
commits. If T1 aborts, then T2 must be aborted
after had been committed.

Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); Recoverable

w1(Y); c1; c2; To make Sc recoverable, c2 of Sc must be
postponed until after T1 commits.
Or else if T1 aborts, then T2 should also abort as
follows:
Se: r1(x); w1(x); r2(x); r1(y);w2(x); w1(y);a1; a2;
 Cont’d
 Cascading rollback (Cascading Abort) is a phenomenon that occurs in some recoverable
schedules when an uncommitted transaction has to be rolled back because it read an item from a
transaction that failed.

 Cascadeless schedule(avoid cascading rollback): A schedule is said to be cascade less, or to

avoid cascading rollback, if every transaction in the schedule reads only items that were written
by committed transactions.

 E.g Sa: r1(X); w1(X); r1(Y);c1 r2(X); w2(X); w1(Y); c2;

 Strict Schedule: A schedule in which a transaction can neither read nor write an item X until the
last transaction that wrote X has committed.

 E.g Sb: w1(X,5);c1 w2(X,8);

 Characterizing Schedules Based on Serializability

 Serial Schedule: A schedule S is serial if, for every transaction T participating in the
schedule, all the operations of T are executed consecutively in the schedule.

 No interleaving occurs in serial schedule

 Eg: Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.

 A serial schedule in which T1 is followed by T2 OR T2 is followed by T1 can be

given as:
 Cont’d
TI T2 TI T2
Read(A) Read(A)

AA-50 TempA*0.1

Write(A) AA-temp

Read(B) Write(A)

B=B+50 Read(B)

Write(B) B=B+temp

Read(A) Write(B)

TempA*0.1 Read(A)

AA-temp AA-50

Write(A) Write(A)

Read(B) Read(B)

B=B+temp B=B+50

Write(B) Write(B)
 Cont’d

 In serial execution there is no interference between transactions, because

only one transaction is executing at any given time. So, it prevents the
occurrence of concurrency problems.

 Serial schedule never leaves the database in an inconsistent sate, therefore

every serial schedule is considered correct.
 Problems of Serial Schedules:

1. They limit concurrency or interleaving of operations.

 If a transaction waits for an I/O operation to complete, we cannot switch

the CPU Processor to another transaction.

2. If some transaction T is long, the other transactions must wait for T to

complete all its operations.
 Non-Serial Schedule (Concurrent Schedule):
 The schedule that is not serial is called non-serial schedule.

 Here each sequence interleaves operations from the two transactions.

 For eg: Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance
from A to B.

 Two non-serial schedules with interleaving of operations for T1 and T2 is

listed below.
 Non Serial Schedule I
TI T2 Non Serial Schedule II
TI T2
Read(A) Cont’d
Read(A)
AA-50
AA-50
Write(A) Read(A)

Read(A) TempA*0.1

TempA*0.1 AA-temp

AA-temp Write(A)

Write(A) Read(B)

Read(B)
Write(A)
B=B+50
Read(B)
Write(B)
B=B+50
Read(B)
Write(B)
B=B + temp B=B + temp

Write(B) Write(B)
 Serial Non-Serial
S1 S2
Example 1
 Suppose Two transaction T1 and T2 running concurrently. T1:Read(A) T1:Read(A)

T1 transfer 100 birr from account A to B , T1:A=A-100 T1:A=A-100

T1:Write(A) T1:Write(A)
T2 transfer 200 birr from account B to C.
T1:Read(B) T2:Read(B)
Let account A=1000,account B=2000 and account C=3000 T1:B=B+100 T2:B=B-200
T1 T2 T1:Write(B) T2:Write(B)
Read(A) Read(B) T2:Read(B) T1:Read(B)
A=A-100 B=B-200 T2:B=B-200 T1:B=B+100
Write(A) Write(B) T2:Write(B) T1:Write(B)
Read(B) Read(C) T2:Read(C) T2:Read(C)
B=B+100 B=C+200 T2:C=C+200 T2:C=C+200
Write(B) Write(C) T2:Write(C) T2:Write(C)
 T1 T2 Cont’d
T1:Read(A)
T1:A=A-100
T1:Write(A)

T2:Read(B)
T2:B=B-200
T2:Write(B)
T1:Read(B)
T1:B=B+100
T1:Write(B)
T2:Read(C)
T2:C=C+200
T2:Write(C)
Non-Serial
 When are two schedules considered equivalent?

 There are several ways to define schedule equivalence.

1. Result Equivalency

2. Conflict Equivalency

3. View Equivalence
 Cont’d

1. Result Equivalent
 Two schedules are called result equivalent if they produce the same final state of
the database.

 Two schedules S1 and S2 are said to be result equivalent if they produce the same
final database state, in other words, they must produce the same result after
execution.

 However two different schedules may accidently produce the same final state.

 Therefore result equivalence is not used to define equivalence of schedules.

 Cont’d
S1 S2
T1 T2 T1 T2
 In both the above schedules,
Read (x) Read (x)
final values on substituting X
x=x+5 x=x+5 and Y as 2 and 5 respectively are

Write (x) X=21 AND Y=10.

Write (x)
Read(y) Read(x)  So both S1 and S2 are result of
X=21 and Y=10
Y=y+5 x=x*3
 Thus, S1 and S2 are Result
W(y) Write (x)
Equivalent Schedules
Read(x) Read(y)
x=x*3 Y=y+5
Write (x) W(y)
2. Conflict Equivalent Cont’d
 Two schedules are said to be conflict equivalent if the order of any two
conflicting operations is the same in both schedules.

 For any 2 given schedules, say S1 and S2 if the order of all possible conflicting
operations is the same in both then it is said to be conflict equivalent.

 If a schedule S can be transformed into a schedule S´ by a series of swaps of non-

conflicting instructions, we say that S and S´ are conflict equivalent.

 S1: r1(A),w1(A),r2(A),w2(A),r1(B),w1(B),r2(B),w2(B)

 S1: r1(A),w1(A), r1(B),w1(B),r2(A),w2(A), r2(B),w2(B)

 Cont’d
Consider the following schedule:

S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)

If Oi and Oj are two operations in a transaction and Oi< Oj (Oi is executed before Oj), same order will follow in the schedule as
well. Using this property, we can get two transactions of schedule S1 as:

T1: R1(A), W1(A), R1(B), W1(B)

T2: R2(A), W2(A), R2(B), W2(B)

 Swapping non-conflicting operations R2(A) and R1(B) in S1, the schedule becomes,

 S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)

Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11, the schedule becomes,

 S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)

S12 is a serial schedule in which all operations of T1 are performed before starting any operation of T2. Since S has been
transformed into a serial schedule S12 by swapping non-conflicting operations of S1, S1 is conflict serializable.
 Conflict Serializable Schedule
Cont’d
 Any given concurrent schedule is said to be conflict serializable schedule if it is conflict equivalent to one
of the possible serial schedule.

 Schedule S is conflict serializable if it is conflict equivalent to some serial schedule S’

Note:

 Being Serializable is distinct from being Serial.

 Two schedules are said to be conflict equivalent if all the conflicting operations in both the schedule get
executed in the same order. If a schedule is a conflict equivalent to its serial schedule then it is called
Conflict Serializable Schedule.
 Precedence Graph
 Precedence Graph is a graph used to test the Conflict Serializability of a Schedule.

 The algorithm looks at only the read item and write item operations in a schedule to
construct a precedence graph.

 It is a directed graph G = (N, E) that consists of a set of nodes N = {T1, T2, ..., Tn }
and a set of directed edges E = {e1,e2, ..., em }.

 There is one node in the graph for each transaction Ti in the schedule.
Algorithm For Testing Conflict Serializability of a Schedule
1. For each transaction Ti participating in schedule S, create a node and labelled it Ti in the precedence
graph.

2. For each case in S where Tj executes a read item(X) after Ti executes a write item(X), create an edge
(Ti→ Tj) in the precedence graph.

3. For each case in S where Tj executes a write item(X) after Ti executes a read item(X), create an edge
(Ti→Tj) in the precedence graph.

4. For each case in S where Tj executes a write item(X) after Ti executes a write item(X), create an
edge (Ti→ Tj) in the precedence graph.

5. The schedule S is serializable if and only if the precedence graph has no cycles.

 (Cycle means - the sequence starts and ends at the same node).
 Cont’d
 Consider the following concurrent schedule for three transactions and specify whether it is
conflict serializable schedule.

 E.g 1 :- R1(X) R2(X) W1(X) R1(Y) W2(X)W1(Y)

T1 T2 T1 T2
R1(X)
R2(X)
W1(X)
R1(Y)
Cycle:- No Conflict Serial
W2(X)
W1(Y)
 Example 2
T1
T1 T2 T3
R(A)
T2 T3
R(B)
R(A)
R(C) From T1T2 there is R(A)-W(A) conflict.

W(B) From T1T3 there is R(B)-W(B) conflict.

From T1T3 there isR(B)
W(B)-R(B) conflict.
R(C)
From T3T2 there is R(C)-W(C) conflict.
W(B)
W(A)
W(C)

There is no cycle or loop in precedence graph. Therefore the given schedule is a conflict
serializable schedule
 Topological Sorting

The process of ordering the nodes of an acrylic graph is known as topological sorting.

We use topological sorting to find the equivalent serial schedule for the conflict
serializable schedule.
 Steps of Topological Sorting
 Step 1: Consider the In-degree of the nodes. Find the nodes with in-degree
zero.
 In-degree= Number of edges coming to the node.

 Out-degree= Number of edges going out of the node

 For the given example, In-degree of T1, I=0 and In-degree of T2, I=1
 Steps of Topological Sorting
 Step 2: Ignore the node whose in-degree is zero and note it down, T1.

 Step 3: Ignore all those edges which is connected with T1

 Step 4: Consider the remaining nodes and continue the above steps again.
 Exercise 1
Consider the following graph for three transactions and specify whether it
supports conflict serializable schedule and write the equivalent serial
schedule.
 Step 1:

Indegree of T1 –0
Indegree of T2 –1
Indegree of T3 –2
Therefore consider T1 first and delete/ignore T1 and all edges from T1.
 Step 2:

•Indegree of T2 –0
•Indegree of T3 –1
•Therefore consider T2 first and delete/ignore T2 and all edges from T2.
 Step 3:

T3

Indegree of T3 – 0
Therefore consider T3

Hence the serial schedule equivalent to the conflict serializable schedule is T1, T2
and T3.
 Exercise:2
Consider the following concurrent schedule for three transactions and specify whether it is
conflict serializable schedule. If it is a conflict serializable schedule find the equivalent
serial schedule.

T1 T2 T3
R(X)
W(X)
W(X)
W(X)
 Cont’d
T1 T2 T3
T1 T2
R(X)
W(X)
W(X) T3

W(X)

 From T1T2 there is R-W conflict,

 From T2T1 there is W-W conflict,

 From T2T3 there is W-W conflict.

 From T1T3 there is W-W conflict.

 There is cycle or loop in precedence graph. Therefore the given schedule is NOT conflict serializable
 Class Work
1, Which of the following schedules is (conflict) serializable? For each serializable schedule,

determine the equivalent serial schedules.

 (a) r3 (X); r2 (X); w3(X); r1(X); w1(X)

 (b) r3 (X); r2 (X); r1(X); w3(X); w1(X)

 3. View Equivalent
 Any given concurrent schedule is said to be view serializable schedule if it is View
EQUIVALENT to one of the possible serial schedule.

 View Equivalent:- Two schedules is said to be view equivalent if the following three conditions hold:

1. Initial Reads: If T1 reads the initial data X in S1, then T1 also reads the initial data X in S2.

2. W-R Conflict: If T1 reads the value written by T2 in S1, then T1 also reads the value written
by T2 in S2.

3. Final Write: If T1 performs the final write on the data value in S1, then it also performs the
final write on the data value in S2.
 Cont’d
Consider the following example:

Schedule 1(S1) Schedule 2(S2)

(Concurrent Schedule) (Serial Schedule)

T1 T2 T3 T2 T3 T1
R(X) R(X)
R(X) R(X)
W(X) W(X)
R(X) R(X)
W(X) W(X)
 Cont’d

Initial Reads: In S1 there are only two initial reads, one from T2 and one from T3.
Similarly in the given serial schedule also there are two initial reads exactly one from T2
and T3 on data item X. So the initial read condition is satisfied here.

W-R Conflict: In S1 there is one write- read conflict from T3 to T1. Similarly there is
write-read conflict from T3 to T1 in S2. So the second condition is also satisfied.

Final write: In S1 the final write on X is from T1, similarly in schedule S2 also the final
write on X is from T1. So the final condition is also satisfied.

Therefore the above given schedule is view serializable.

 Example Similarity 1: A1=B1 both statement read the value from the
Schedule A Schedule B DB

 Similarity 2: A4 reads a value written by A3

No T1 T2 T2 T3
1 R(X) R(X)  Similarity 2: B7 read the value written by B3
2 X=X-N X=X-N
 Similarity 4: A7 reads the value of Y from the DB
3 W(X) W(X)
 Similarity 4: B4 reads a value of Y from DB
4 R(X) R(Y)
5 X=X+M Y=Y+N Similarity 3: A9 in T1 is last statement that update value of Y
6 W(X) W(Y)
Similarity 3:B6 in T2 is last statement that update value of Y
7 R(Y) R(X)
8 Y=Y+N X=X+M
9 W(Y) W(X) Since Schedule A is View Equivalent to Schedule B it is Called
View Serializable
 Th
an
ky
ou
!!
82