Anubhav Sharma (A.P.

CSE)

Transaction Processing Concepts

DATABASE MANAGEMENT SYSTEMS
UNIT-IV

by
Anubhav Sharma
Asstt. Professor
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
 Anubhav Sharma (A.P. CSE)

Transaction State Diagram / State Transition Diagram

Fig.: State Transition Diagram for a Database Transaction

Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
 Anubhav Sharma (A.P. CSE)
IMPLEMENTATION OF ATOMICITY AND DURABILITY

Atomicity can be defined as a transaction involving two or more discrete pieces of information, either
all of the pieces are committed or none are.
Durability is nothing but a committed data saved by the system such that, even in the event of a failure
and system restart, the data is available in its correct state. The recovery-management component of
a database system implements the support for atomicity and durability. The atomicity and durability
properties of transactions are ensured by the shadow-copy implementation of the recovery-
management component.
 The shadow-database scheme:
 Assume that only one transaction is active at a time.
 A pointer called db_pointer always points to the current consistent copy of the database.
 All updates are made on a shadow copy of the database, and db_pointer is made to point to the
updated shadow copy only after the transaction reaches partial commit and all updated pages
have been flushed to disk.
 In case transaction fails, old consistent copy pointed to by db_pointer can be used, and the
shadow copy can be deleted.
 Anubhav Sharma (A.P. CSE)
IMPLEMENTATION OF ATOMICITY AND DURABILITY

Fig. : The shadow-database scheme

■ Assumes disks to not fail

■Useful for text editors, but extremely inefficient for large databases: executing a single transaction
requires copying the entire database.
 CONCURRENT EXECUTIONS Anubhav Sharma (A.P. CSE)

 Multiple transactions are allowed to run concurrently in the system.

Advantages are:
 Increased processor and disk utilization, leading to better transaction throughput: one
transaction can be using the CPU while another is reading from or writing to the disk.
 Reduced average response time for transactions: short transactions need not wait
behind long ones.

 Concurrency control schemes – mechanisms to achieve isolation, i.e., to control the

interaction among the concurrent transactions in order to prevent them from
destroying the consistency of the database.
Anubhav Sharma (A.P. CSE)
 Anubhav Sharma (A.P. CSE)

Example of Schedule(serial schedule):

 Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B. The following example is a
serial schedule in which T1 is followed by T2.
 Anubhav Sharma (A.P. CSE)

Example of Schedule
Let T1 and T2 be the transactions defined previously. The following schedule is not a serial schedule, but it is
equivalent to Schedule 1.

Note: In both Schedule 1 and 2, the sum A + B is preserved.

 Anubhav Sharma (A.P. CSE)

Example of Schedule(concurrent schedule ):

The following concurrent schedule does not preserve the value of the sum A + B.
 Anubhav Sharma (A.P. CSE)

SERIALIZABILITY:
Serializability is a concurrency scheme where the concurrent transaction is equivalent
to one that executes the transactions serially.
Depending on the type of schedules, there are two types of serializability:
1. conflict serializability
2. view serializability

The main objective of serializability is to find non-serial schedules that allow

transactions to execute concurrently without interference and produce a database state
that could be produced by a serial execution.
Conflict Serializability Anubhav Sharma (A.P. CSE)
A schedule is called conflict serializable if we can convert it into a serial schedule after
swapping its non-conflicting operations.

Conflicting operations
Two operations are said to be in conflict, if they satisfy all the following three conditions:
1. Both the operations should belong to different transactions.
2. Both the operations are working on same data item.
3. At least one of the operation is a write operation.
Conflict Serializability Continued… Anubhav Sharma (A.P. CSE)

Some examples to understand Conflict Serializability

Example 1: Operation W(X) of transaction T1 and operation R(X) of transaction T2
are conflicting operations, because they satisfy all the three conditions mentioned
above. They belong to different transactions, they are working on same data item X,
one of the operation in write operation.
Example 2: Similarly Operations W(X) of T1 and W(X) of T2 are conflicting
operations.
Example 3: Operations W(X) of T1 and W(Y) of T2 are non-conflicting operations
because both the write operations are not working on same data item so these
operations don’t satisfy the second condition.
Example 4: Similarly R(X) of T1 and R(X) of T2 are non-conflicting operations
because none of them is write operation.
Example 5: Similarly W(X) of T1 and R(X) of T1 are non-conflicting operations
because both the operations belong to same transaction T1.
Conflict Serializability Continued… Anubhav Sharma (A.P. CSE)

Conflict Equivalent Schedules

Two schedules are said to be conflict Equivalent if one schedule can be converted into other schedule after swapping
non-conflicting operations.

Conflict Serializable check

Lets check whether a schedule is conflict serializable or not. If a schedule is conflict Equivalent to its serial schedule
then it is called Conflict Serializable schedule. Lets take few examples of schedules.
Example of Conflict Serializability
Lets consider this schedule:
T1 T2

R(A)
R(B)
R(A)
R(B)
W(B)
W(A)
To convert this schedule into a serial schedule we must have to swap the R(A) operation of transaction T2 with the
W(A) operation of transaction T1. However we cannot swap these two operations because they are conflicting
operations, thus we can say that this given schedule is not Conflict Serializable.
Conflict Serializability Continued… Anubhav Sharma (A.P. CSE)
Conflict Serializability Continued… Anubhav Sharma (A.P. CSE)
View Serializability Anubhav Sharma (A.P. CSE)

View Serializability is a process to find out that a given schedule is view serializable or not.
To check whether a given schedule is view serializable, we need to check whether the given schedule is View
Equivalent to its serial schedule. Lets take an example to understand what I mean by that.

Given Schedule:

T1 T2
R(X)
W(X)
R(X)
W(X)
R(Y)
W(Y)
R(Y)
W(Y)
View Serializability continued.. Anubhav Sharma (A.P. CSE)

Serial Schedule of the above given schedule:

As we know that in Serial schedule a transaction only starts when the current running transaction is finished. So the serial
schedule of the above given schedule would look like this:

T1 T2
R(X)
W(X)
R(Y)
W(Y)
R(X)
W(X)
R(Y)
W(Y)

If we can prove that the given schedule is View Equivalent to its serial schedule then the given schedule is called view
Serializable.
View Serializability continued.. Anubhav Sharma (A.P. CSE)

Why we need View Serializability?

We know that a serial schedule never leaves the database in inconsistent state because there are no
concurrent transactions execution. However a non-serial schedule can leave the database in inconsistent
state because there are multiple transactions running concurrently. By checking that a given non-serial
schedule is view serializable, we make sure that it is a consistent schedule.
You may be wondering instead of checking that a non-serial schedule is serializable or not, can’t we have
serial schedule all the time? The answer is no, because concurrent execution of transactions fully utilize the
system resources and are considerably faster compared to serial schedules.
View Serializability continued.. Anubhav Sharma (A.P. CSE)

View Equivalent
Lets learn how to check whether the two schedules are view equivalent.
Two schedules T1 and T2 are said to be view equivalent, if they satisfy all the following conditions:

1.Initial Read: Initial read of each data item in transactions must match in both schedules. For example, if transaction
T1 reads a data item X before transaction T2 in schedule S1 then in schedule S2, T1 should read X before T2.

Read vs Initial Read: You may be confused by the term initial read. Here initial read means the first read operation on
a data item, for example, a data item X can be read multiple times in a schedule but the first read operation on X is
called the initial read. This will be more clear once we will get to the example.

2.Final Write: Final write operations on each data item must match in both the schedules. For example, a data item X
is last written by Transaction T1 in schedule S1 then in S2, the last write operation on X should be performed by the
transaction T1.

3.Update Read: If in schedule S1, the transaction T1 is reading a data item updated by T2 then in schedule S2, T1
should read the value after the write operation of T2 on same data item. For example, In schedule S1, T1 performs a
read operation on X after the write operation on X by T2 then in S2, T1 should read the X after T2 performs write on X.
View Serializability continued.. Anubhav Sharma (A.P. CSE)

If a schedule is view equivalent to its serial schedule then the given schedule is said to be View Serializable.
Example:

Lets check the three conditions of view serializability

View Serializability continued.. Anubhav Sharma (A.P. CSE)

 Initial Read
In schedule S1, transaction T1 first reads the data item X. In S2 also transaction T1 first reads the data item X.
Lets check for Y. In schedule S1, transaction T1 first reads the data item Y. In S2 also the first read operation on
Y is performed by T1.
We checked for both data items X & Y and the initial read condition is satisfied in S1 & S2.

 Final Write
In schedule S1, the final write operation on X is done by transaction T2. In S2 also transaction T2 performs the final
write on X.
Lets check for Y. In schedule S1, the final write operation on Y is done by transaction T2. In schedule S2, final write
on Y is done by T2.
We checked for both data items X & Y and the final write condition is satisfied in S1 & S2.

 Update Read
In S1, transaction T2 reads the value of X, written by T1. In S2, the same transaction T2 reads the X after it is
written by T1.
In S1, transaction T2 reads the value of Y, written by T1. In S2, the same transaction T2 reads the value of Y after it
is updated by T1.
The update read condition is also satisfied for both the schedules.
Result: Since all the three conditions that checks whether the two schedules are view equivalent are satisfied in this
example, which means S1 and S2 are view equivalent. Also, as we know that the schedule S2 is the serial schedule of
S1, thus we can say that the schedule S1 is view serializable schedule.
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Anubhav Sharma (A.P. CSE)
Recoverability in DBMS: Anubhav Sharma (A.P. CSE)

A transaction may not execute completely due to hardware failure, system crash or software
issues. In that case, we have to roll back the failed transaction. But, some other transaction
may also have used values produced by the failed transaction. So, we have to roll back those
transactions as well.

Classification of Recoverability:
Recoverable Schedules Anubhav Sharma (A.P. CSE)

 Schedules in which transactions commit only after all transactions whose changes they read commit
are called recoverable schedules.
In other words, if some transaction Tj is reading value updated or written by some other transaction Ti,
then the commit of Tj must occur after the commit of Ti.
EX-1:
S1: R1(x), W1(x), R2(x), R1(y), R2(y), W2(x), W1(y), C1, C2;
Given schedule follows order of Ti->Tj => C1->C2. Transaction T1 is executed before T2 hence there is no chances
of conflict occur. R1(x) appears before W1(x) and transaction T1 is committed before T2 i.e. completion of first
transaction performed first update on data item x, hence given schedule is recoverable.
EX-2:
Consider the following schedule involving two transactions T1 and T2.
T1 T2
R(A)
W(A)
W(A)
R(A)
COMMIT
This is a recoverable schedule since T 1 commits before T 2, that
COMMIT makes the value read by T2 correct.
Strictly Recoverble Schedule Anubhav Sharma (A.P. CSE)

If in a schedule, a transaction is neither allowed to read nor write a data item until the last transaction
that has written it is committed or aborted, then such a schedule is called as a Strict Schedule.
In other words,
•Strict schedule allows only committed read and write operations.
•Clearly, strict schedule implements more restrictions than cascadeless schedule.

Ex:
Recoverable with Cascading Rollback / Schedule /Abort Anubhav Sharma (A.P. CSE)

 In a schedule, failure of one transaction causes several other dependent transactions to rollback or abort, then such a
schedule is called as a Cascading Schedule or Cascading Rollback or Cascading Abort.

In otherwords, If transaction Tj is reading value updated by transaction Ti and commit of Tj is delayed till commit of Ti,
the schedule is called recoverable with cascading rollback.
Ex:
The table below shows a schedule with two transactions, T1 reads and writes A and that value is read and written by T2.
But later on, T1 fails. So we have to rollback T1. Since T2 has read the value written by T1, it should also be rollbacked.
As it has not committed, we can rollback T2 as well. So it is recoverable with cascading rollback.

Note:
• It simply leads to the wastage of CPU time.
• If the transaction T2 would have committed
before the failure of transaction T1, then the
schedule would have been irrecoverable.
Recoverable with Cascadeless Rollback / Schedule /Abort Anubhav Sharma (A.P. CSE)

If in a schedule, a transaction is not allowed to read a data item until the last transaction that has written it is committed
or aborted, then such a schedule is called as a Cascadeless Schedule.
In other words,
• Cascadeless schedule allows only committed read operations.
• Therefore, it avoids cascading roll back and thus saves CPU time.
i.e. If Tj reads value updated by Ti only after Ti is committed, the schedule will be cascadeless recoverable.
Ex:
The table below shows a schedule with two transactions, T1 reads and writes A and commits and that value is read by
T2. But if T1 fails before commit, no other transaction has read its value, so there is no need to rollback other
transaction. So this is a Cascadeless recoverable schedule.

Note:
• Cascadeless schedule allows only committed read operations
• However, it allows uncommitted write operations.
Recoverability Continued… Anubhav Sharma (A.P. CSE)

Note:
 Strict schedules are more strict than cascadeless schedules.
 All strict schedules are cascadeless schedules.
 All cascadeless schedules are not strict schedules
Irrecoverable Schedule Anubhav Sharma (A.P. CSE)

In a schedule,
 A transaction performs a dirty read operation from an uncommitted transaction
 And commits before the transaction from which it has read the value then such a schedule is known as
an Irrecoverable Schedule.
In otherwords, when Tj is reading the value updated by Ti and Tj is committed before committing of Ti, the
schedule will be irrecoverable.
Ex:
The table below shows a schedule with two transactions, T1 reads and writes A and that value is read and written by T2.
T2 commits. But later on, T1 fails. So we have to rollback T1. Since T2 has read the value written by T1, it should also
be rollbacked. But we have already committed that. So this schedule is irrecoverable schedule.

A dirty read occurs when one transaction is permitted to read data that
is being modified by another transaction which is running concurrently
but which has not yet committed itself. If the transaction that modifies
the data commits itself, the dirty read problem doesn't occur.
TESTING FOR SERIALIZABILITY Anubhav Sharma (A.P. CSE)

Serialization Graph is used to test the Serializability of a schedule.

Assume a schedule S. For S, we construct a graph known as precedence graph. This graph has a pair G
= (V, E), where V consists a set of vertices, and E consists a set of edges. The set of vertices is used to
contain all the transactions participating in the schedule. The set of edges is used to contain all edges Ti ->Tj
for which one of the three conditions holds:

1. Create a node for each transaction.

2.Create a direct edge Ti → Tj if Ti executes write (Q) before Tj executes read (Q).
3.Create a direct edge Ti → Tj if Ti executes read (Q) before Tj executes write (Q).
4.Create a direct edge Ti → Tj if Ti executes write (Q) before Tj executes write (Q).

 If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti are executed before the first
instruction of Tj is executed.
 If a precedence graph for schedule S contains a cycle, then S is non-serializable. If the precedence graph has no
cycle, then S is known as serializable.
TESTING FOR SERIALIZABILITY Continued… Anubhav Sharma (A.P. CSE)

EX: Explanation:
Create Nodes for the transactions T1, T2, T3.
Read(A): In T4,no subsequent writes to A, so no new edges
Read(C): In T4, no subsequent writes to C, so no new edges
Write(A): A is subsequently read by T5, so add edge T4 → T5
Read(B): In T5,no subsequent writes to B, so no new edges
Write(C): C is subsequently read by T6, so add edge T4 → T6
Write(B): B is subsequently read by T6, so add edge T5 → T6
Write(C): In T6, no subsequent reads to C, so no new edges
Write(A): In T5, no subsequent reads to A, so no new edges
Write(B): In T6, no subsequent reads to B, so no new edges
Precedence graph for schedule S2:

The precedence graph for schedule S2 contains no cycle that's why ScheduleS2 is serializable
 TESTING FOR SERIALIZABILITY Continued… Anubhav Sharma (A.P. CSE)

EX: T1 T2 T3 Explanation:
Read(A) Create Nodes for the transactions T1, T2, T3.
Read(B) Read(A): In T1, no subsequent writes to A, so no new edges
A:=f1(A) Read(B): In T2, no subsequent writes to B, so no new edges
Read(C) Read(C): In T3, no subsequent writes to C, so no new edges
B:=f2(B) Write(B): B is subsequently read by T3, so add edge T2 → T3
Write(B)
Write(C): C is subsequently read by T1, so add edge T3 → T1
Write(A): A is subsequently read by T2, so add edge T1 → T2
Schedule S1

C:=f3(C)
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C)
Write(C): In T1, no subsequent reads to C, so no new edges
Write(A) PWrerciteed(eBn)c:eIngrTa3p,hnofosrusbcsheqedueunletrSe1a:dsto B, so no new edges
Read(B)
Read(A)
A=f4(A)
T1
Read(C)
Write(A)
C:=f5(C)
Write(C) T2 T3
B:=f6(B)
Write(B)

The precedence aph for schedule S1 contains a cy cle that's why Schedule S1 is non-serializable.
Testing Serializability Continued… Anubhav Sharma (A.P. CSE)

We know that
 The concept of serializability helps to identify the correct non-serial schedules that will maintain the consistency of
the database.
 There are two types of serializability-
Testing Conflict Serializability Anubhav Sharma (A.P. CSE)

Problem-1: Check whether the given schedule S is Conflict serializable or not-

T1 T2 T3 Precedence graph Conflict
 Create Nodes for the transactions T1, T2, T3. Operations
R(x)
 Check Conflict pairs in other transactions
R(y) and draw edges. R-W
R(x) W-R
W-W
R(y) T1
R(z) 3 1
W(y)
W(z) T2 2 T3
R(z)
W(x)
W(z)

• Clearly, there ex ists no cycle in the precedence graph.

• Therefore, the gi ven schedule S is conflict serializable
• Thus, we conclud e that the given schedule is conflic.
Testing View Serializability Anubhav Sharma (A.P. CSE)

Problem-1: Check whether the given schedule S is view serializable or not-

Solution:
• We know, if a schedule is conflict serializable, then it is surely
view serializable.
• So, let us check whether the given schedule is conflict serializable
or not.
Checking Whether S is Conflict Serializable Or Not
Step-01: Step-02:
List all the conflicting operations precedence graph
and determine the dependency
between the transactions-
W1(B) , W2(B) (T1 → T2)
W1(B) , W3(B) (T1 → T3)
W1(B) , W4(B) (T1 → T4)
W2(B) , W3(B) (T2 → T3)
W2(B) , W4(B) (T2 → T4)
W3(B) , W4(B) (T3 → T4)

•Clearly, there exists no cycle in the precedence graph.

•Therefore, the given schedule S is conflict serializable.
•Thus, we conclude that the given schedule is also view serializable.
 Anubhav Sharma (A.P. CSE)

END OF UNIT 4