Asansol

Engineering
College
Database Management System
 2

Topics to be covered
What is Transaction
Problems in Transaction
ACID property of Transaction
Transaction States
Concurrency in Transactions
Problems in Concurrent Transaction
Schedule ( Serial & Concurrent)
Serializability
What is Transaction
Transaction Concept

Transaction Concept
A transaction is a unit of program execution that accesses and
possibly updates various data items
A transaction is a logical unit of work that contains one or more
SQL statements. The effects of all the SQL statements in a
transaction can be either all committed or all rolled back

A transaction that changes the contents of the database must

alter the database from one consistent database state to
another
ACID Properties...

Let T1 be a transaction that transfers Rs100 from account A to account B

T1
Read(A);
A:=A-100;
Write(A);
Read(B);
B:=B+100;
Write(B);

1.Atomicity: The database system keeps track of the old values of any data on
which a transaction performs a write, and if the transaction does not complete
its execution, the database system restores the old values to make it appear as
though the transaction never executed
• Ensuring atomicity is the responsibility of the database system itself. It is
handled by the transaction management component
ACID Properties...

2. Consistency: Sum of A and B be unchanged by the execution of the transaction

• Ensuring the consistency for an individual transaction is
the responsibility of the application programmers who codes the transaction
3. Isolation: The database is temporarily inconsistent while the transaction to transfer
funds from account A to B is executing. The solutions are:
• Execute transactions serially
• However, concurrent execution of transactions provides significant performance
benefits such as increased throughputs
• Ensuring the isolation property is the responsibility of concurrency control
component of the database system
4. Durability: Once a transaction completes successfully, all the updates that is
carried out on the database persist, even if there is a system failure after the
transaction completes execution
• Ensuring durability is the responsibility of recovery management component
of the database system
 Transaction States
• Active state: This state is the initial state of a transaction. The transaction stays in this
state while it is executing.
• Partial Committed state: A transaction is partial
committed after its final statement has been executed. A
transaction enters this state immediately before the
commit statement

• Failed state: A transaction enters the failed state after the

discovery that normal execution can no longer proceed

• Aborted state: A transaction is aborted after it has been

rolled back and the database is restored to its prior state
before the transaction

• Committed state: Committed state occurs after

successful completion of the transaction

• Terminate: Transaction is either committed or aborted 19.7

Concurrent Transaction
Advantages of Concurrent Executions

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

Advantages are:
╺ Increased processor and disk utilization, leading to better
transaction throughput.
╺ E.g. 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.
╺ Increase Resource Utilization and Efficiency
▰ Concurrency control schemes – mechanisms to achieve isolation
╺ That is, to control the interaction among the concurrent
transactions to prevent them from destroying the consistency of
the database
Disadvantages/Problems of Concurrent Executions

▰ Problems in concurrent Transactions

╺ Lost Update Problem (WW conflict)
╺ Dirty Read Problem (WR conflict; W is temporal)
╺ Unrepeatable Read Problem ( RR conflict)
╺ Phantom Read Problem (RR conflict)
╺ Incorrect Summary Problem (RW conflict)
 Need of Concurrency Control
Lost Update Problem-- WW conflict
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 item incorrect

T1 T2
Read(A);
A:=A-100;
Read(A);
Temp=0.2*A;
A:=A-Temp;
Write(A);
Write(A);
Read(B);
B:=B+100;
Write(B);
 Need of Concurrency
Control...

Temporary Update(or Dirty Read) Problem- WR conflict

This problem occurs when one transaction updates a
database item and then the transaction fails due to
some reason. The updated item is accessed by
another transaction before it is changed back to its
original value

T1 T2

Read(A);
A:=A-100;
Write(A);
Read(A);
Temp=0.2*A;
A:=A-Temp;
Write(A);
Read(B);
B:=B+100;
 Need of Concurrency 13

Control...
Unrepeatable Read Problem
It happens when two or more
different values of the same data
are Read during the read operation
in the same transaction.

Phantom Read Problem

The same data is read through two
different read operations in the
same transaction. In the first read
operation, a value is obtained but in
the second operation an error is
obtained.
 Need of Concurrency
Control...
Incorrect Summary Problem
If one transaction is calculating an aggregate
summary function on several records while other
transactions are updating some of these records,
the aggregate function may calculate some values
before they are updated and others after they are
updated

T1 T2
sum=0;
Read(A);
A:=A-100;
Write(A);
Read(A);
sum:=sum+A;
Read(B);
sum:=sum+B;
Read(B);
B:=B+100;
Write(B);
21.14
Concurrent Execution
and
Schedule
Concurrent Execution
Concurrent Execution

Concurrent execution of transactions means executing more

than one transaction at the same time

In the serial execution, one transaction can start executing only

after the completion of the previous

The advantages of using concurrent execution of transactions

are:
• Improved throughput and resource utilization
• Reduced waiting time
The database system must control the interaction among the
concurrent transactions to prevent them from destroying the
consistency of the database. It does this through a variety of
mechanisms called concurrency control schemes
Schedules

▰ Schedule – 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
╺ Must preserve the order in which the instructions appear in each
individual transaction.
▰ A transaction that successfully completes its execution will have a commit
instructions as the last statement
╺ By default transaction assumed to execute commit instruction as its
last step
▰ A transaction that fails to successfully complete its execution will have an
abort instruction as the last statement
Serial Schedule

Serial Schedule

A serial schedule is a schedule where all the instructions belonging to each

transaction appear together
There is no interleaving of transaction operations. A serial schedule has no
concurrency and therefore it does not interleave the actions of different
transactions

For n transactions, there are exactly n! different serial schedules

possible
Serial Schedule...
T1 T2
Read(A);
A:=A-100;
Write(A);
Schedule1 (T1 followed by T2) Read(B);
B:=B+100;
Write(B);
Read(A);
Temp=0.2*A;
A:=A-Temp;
Write(A);
Read(B);
B:=B+Temp;
Write(B);

T1 T2
Read(A);
Temp=0.2*A;
A:=A-Temp;
Write(A);
Schedule2 (T2 followed by T1) Read(B);
B:=B+Temp;
Write(B);
Read(A);
A:=A-100;
Write(A);
Read(B);
B:=B+100;
Write(B);
 Concurrent Schedule
Concurrent Schedule
In a concurrent schedule, operations from different concurrent transactions are
interleaved.

The number of possible schedules for a set of n transactions is much larger than n!

Schedule1
T1 T2 Schedule3
Read(A);
A:=A-100;
Write(A);
Read(A);
Temp=0.2*A;
A:=A-Temp;
Write(A);

Read(B);
B:=B+100;
Write(B);
Read(B);
B:=B+Temp;
Write(B);
Concurrent Schedule...

Schedule3
Schedule4 Schedule5
T1 T2 T1 T2 T1 T2
Read(A); Read(A); Read(A);
A:=A-100; A:=A-100; A:=A-100;
Read(A);
Write(A); Write(A);
Read(A); Temp=0.2*A;
Read(A);
Temp=0.2*A; A:=A-Temp;
Temp=0.2*A;
A:=A-Temp; Write(A);
A:=A-Temp;
Write(A); Read(B); Read(B);

Read(B); Write(A); B:=B+100;

Write(A);
B:=B+100; Read(B);
Read(B);
Write(B); B:=B+100;
Read(B); B:=B+Temp;
Write(B);
B:=B+Temp; B:=B+Temp; Write(B);

Write(B); Write(B); Write(B);

Schedule 1-Serial Schedule

▰ Let T1 transfer 50 from A to B, and T2 transfer 10% of the balance from A to B.

▰ An example of a serial schedule in which T1 is followed by T2 :
Schedule 2 – Serial Schedule

▰ A serial schedule in which T2 is followed by T1 :

Schedule 3 – Concurrent 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 schedules 1, 2 and 3, the sum “A + B” is preserved.

Schedule 4 – Concurrent Schedule

▰ The following concurrent schedule does not preserve the sum of “A + B”

Serializability

Serializability
A concurrent schedule is serializable if it is equivalent to a
serial schedule

Serial schedules preserve consistency as we assume each

transaction individually preserves consistency

The database system must control concurrent execution of

transactions to ensure that the database state remains
consistent

Since the modifications are done in the local buffer, we can

ignore the operations other than Read and Write instructions
for easier understanding of the serializability
Serializability...
T1 T2 T1 T2
Read(A); Read(A);
Write(A); Write(A);
Read(B); Read(B);
Write(B); Write(B);
Read(A); Read(A);
Write(A); Write(A);
Read(B); Read(B);
Write(B); Write(B);
Schedule1 Schedule2

T1 T2 T1 T2 T1 T2
Read(A); Read(A); Read(A);
Write(A); Read(A); Write(A);
Read(A); Write(A); Read(A);
Write(A); Read(B); Read(B);
Read(B); Write(A); Write(A);
Write(B); Read(B); Read(B);
Read(B); Write(B);
Write(B)
Write(B); Write(B); Write(B);
Schedule3 Schedule4 Schedule5
Serializability

▰ Basic Assumption – Each transaction preserves database consistency.

▰ Thus, serial execution of a set of transactions preserves database
consistency.
▰ A (possibly concurrent) schedule is serializable if it is equivalent to a serial
schedule. Different forms of schedule equivalence give rise to the notions of:
1. conflict serializability
2. view serializability
 Conflicting Instructions

▰ Let li and lj be two Instructions of transactions Ti and Tj respectively.

Instructions li and lj conflict if and only if there exists some item Q
accessed by both li and lj, and at least one of these instructions wrote Q.
1. li = read(Q), lj = read(Q). li and lj don’t conflict.
2. li = read(Q), lj = write(Q). They conflict.
3. li = write(Q), lj = read(Q). They conflict
4. li = write(Q), lj = write(Q). They conflict
▰ Intuitively, a conflict between li and lj forces a (logical) temporal order
between them.
╺ If li and lj are consecutive in a schedule and they do not conflict,
their results would remain the same even if they had been
interchanged in the schedule.
Conflict Serializability

▰ 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.
▰ We say that a schedule S is conflict serializable if it is
conflict equivalent to a serial schedule
Conflict Serializability (Cont.)

▰ Schedule 3 can be transformed into Schedule 6 -- a serial schedule

where T2 follows T1, by a series of swaps of non-conflicting instructions.
Therefore, Schedule 3 is conflict serializable.

Schedule 3 Schedule 6
Conflict Serializability (Cont.)–Example of Conflict Serializable

▰ Example of a schedule that is not conflict serializable:

▰ We are unable to swap instructions in the above schedule to obtain

either the serial schedule < T3, T4 >, or the serial schedule < T4, T3 >.
 Precedence Graph

▰ Consider some schedule of a set of transactions T1, T2, ..., Tn

▰ Precedence graph — a direct graph where the vertices are the transactions
(names).
▰ We draw an arc from Ti to Tj if the two transaction conflict, and Ti accessed
the data item on which the conflict arose earlier.
▰ We may label the arc by the item that was accessed.
▰ Example
 Testing for Conflict Serializability

▰ A schedule is conflict serializable if and only if its

precedence graph is acyclic.
▰ Cycle-detection algorithms exist which take order n2
time, where n is the number of vertices in the graph.
╺ (Better algorithms take order n + e where e is
the number of edges.)
▰ If the precedence graph is acyclic, the serializability
order can be obtained by a topological sorting of the
graph.
╺ That is, a linear order consistent with the partial
order of the graph.
╺ For example, a serializability order for the
schedule (a) would be one of either (b) or (c)
 35
Testing for Conflict Serializability
T1 T2 T3
T1 T2
R(X)

R(Y)
R(X)
R(Y) As No cycle is formed in the Among 6 possible serial
R(Z) Precedence graph, So we can schedule which one is actually
W(Y) Say that the schedule is T3 holding?
Conflict Serializable. To find out that we have to do
W(Z) Topological Sorting
R(Z) s1 T1 T2 T3
W(X)
W(Z) T1 T2 s2 T1 T3 T2

s3 T2 T1 T3

s4 T2 T3 T1
T2 T3 T1
s5 T3 T1 T2
T3
s6 T3 T2 T1
 View Serializability

▰ Let S and S´ be two schedules with the same set of transactions. S and S´ are view
equivalent if the following three conditions are met, for each data item Q,

1.Initial Read Sequence Maintain: If in schedule S, transaction Ti reads the initial

value of Q, then in schedule S’ also transaction Ti must read the initial value of Q.
2.Write - Read Sequence Maintain If in schedule S transaction Ti executes read(Q),
and that value was produced by transaction Tj (if any), then in schedule S’ also
transaction Ti must read the value of Q that was produced by the same write(Q)
operation of transaction Tj .
3.Final Write Maintain The transaction (if any) that performs the final write(Q)
operation in schedule S must also perform the final write(Q) operation in schedule
S’.

▰ As can be seen, view equivalence is also based purely on reads and writes alone.
 View Serializability (Cont.) S1 : Serial schedule <T1,T2>
37

Is S a View Serializable? Two serial Schedules are possible

S1 <T1,T2> and S2 <T2,T1>
A schedule S is view
serializable if it is view Check 3 conditions are preserved
equivalent to a serial in S ? w.r.t S1
schedule. S or w.r.t S2

1. Initial Read Sequence Maintain

2. Write - Read Sequence Maintain
3. Final Write Maintain
S2 : Serial schedule <T2,T1>
If S2 is being checked with S, then
In S2, transaction T2 Read(A) first
But in S, this initial Read sequence is
Not maintained. So S is not View
Serializable with S2.

If S1 is being checked with S, then in S the initial Read(A) is done by T1 and in S1

also initial Read(A) is done by T1. Same initial read is applicable to Reab(B). Final
Write is also maintained. In S, T1 Writes(A) T2 Read(A) and T1 Write(B) and T2
Read (B). All conditions are satisfied. So we can say S is View serializable with S1.
 View Serializability (Cont.) 38
s1 T1 T2 T3
Is S a View Serializable? N!, 6 serial Schedules are possible
s2 T1 T3 T2
Check 3 conditions are preserved in S?
s3 T2 T1 T3
w.r.t S1,S2,S3,S4,S5,S6
S
s4 T2 T3 T1
1. Initial Read Sequence Maintain
2. Write - Read Sequence Maintain s5 T3 T1 T2
3. Final Read Maintain
s6 T3 T2 T1

Check S with S1
Initial Read(Q) in S (by T1) is maintained by T1 of S1.
Final Write(Q) in S (by T3) is maintained by T3 of S1.
After writing no Read() is there ; so 2nd condition is not
Applicable.

So we can say that S is view serializable with S1.

Is S a Conflict Serializable Schedule ?

 View Serializability (Cont.) 39

Is S a Conflict Serializable Schedule ? Make precedence Graph

S
T1 T2

T3

The cycle is Found. So, the schedule

Blind write : Write operation
can’t be Conflict Serializable.
Without Read

Every view-serializable is not conflict-serializable.

Every conflict serializable schedule is also view serializable.

When a Blind write is present in view serializable schedule then that Schedule cannot be in
conflict serializable .
Test for View Serializability

▰ The precedence graph test for conflict serializability cannot be used

directly to test for view serializability.
╺ Extension to test for view serializability has cost exponential in
the size of the precedence graph.
▰ The problem of checking if a schedule is view serializable falls in the
class of NP-complete problems.
╺ Thus, existence of an efficient algorithm is extremely unlikely.
▰ However ,practical algorithms that just check some sufficient
conditions for view serializability can still be used.
 41
Recoverable Schedule Dirty
S1 S2 Read
?
T1 T2 T1 T2 YES NO
R(A) R(A)
A=A+10 A=A+10 Commit Recoverable
sequence as YES Schedule
W(A) W(A) per
R(A) R(A) dependency
Dirty read A=A-5 A=A-5 ?
Dirty read Dependency:
W(A) W(A) T1 Write(A) → Then → T2 Read(A)
COMMIT NO
COMMIT So, T1 should Commit first, then T2
FAIL
COMMIT COMMIT Not
Recoverable
T1 should Commit Schedule
Problem first, then T2

Recoverable schedule — if a transaction Tj reads

a data item previously written by a transaction Ti ,
then the commit operation of Ti must appear
before the commit operation of Tj.
 Cascading Rollbacks

▰ Cascading rollback – a single transaction failure leads to a series of

transaction rollbacks. Consider the following schedule where none of the
transactions has yet been committed (so the schedule is recoverable)

▰ If T10 fails, T11 and T12 must also be rolled back.

▰ Can lead to the undoing of a significant amount of work
 Cascadeless Schedules
▰ Cascadeless schedules — for each pair of transactions Ti and Tj such
that Tj reads a data item previously written by Ti, the commit
operation of Ti appears before the read operation of Tj.
▰ Every cascadeless schedule is also recoverable

Recoverable

Cascadeless
 44
Cascadeless Schedules

T1 T2 T3
R(A)
W(A)
Dirty Read R(A)
W(A)

Dirty Read
R(A)
FAIL
Commit
commit
T1 T2 T3
commit
R(A)
Order of dependency is T1→T2→T3 W(A)
So, commit should be T1 →then T2 →then T3 Commit

If a failure occurs here then T1 will If there is no dirty read then R(A)
cascadeless schedule is obtained. W(A)
Rollback and T2 , T3 will also Commit
Rollback. So such type of schedule
is known as Cascading Rollback Degree of concurrency is R(A)
decreased Commit
Schedule
THANK YOU...
 46
Cascadeless Schedules

T1 T2 T3
R(A)
W(A)
Dirty Read R(A)
W(A)

Dirty Read
R(A)
FAIL
Commit
commit
T1 T2 T3
commit
R(A)
Order of dependency is T1→T2→T3 W(A)
So, commit should be T1 →then T2 →then T3 Commit

If a failure occurs here then T1 will If there is no dirty read then R(A)
cascadeless schedule is obtained. W(A)
Rollback and T2 , T3 will also Commit
Rollback. So such type of schedule
is known as Cascading Rollback Degree of concurrency is R(A)
decreased Commit
Schedule