CONCURRENCY

CONTROL
Instructor: Saba Saeed
 Agenda

01
• Concurrency Control
-Serial vs Interleaved schedule
• Concurrency Issues
– Lost Update,
- Dirty Read,
-Non-repeatable read,
-Inconsistent Retrieval
02
• Serializability
-Conflict Serializability
- View Serializability
- Precedence Graph
•Recoverability
-Irrecoverable Schedules
-Recoverable Schedules
 T1 T2 ---- ---- R(A) R(B) W(A) commit R(B) R(A) W(B) commit

Serial Vs Interleaved Schedules

Serial schedule

◦ Transaction is executed completely before

starting the execution of another
transaction. In other words, you can say
that in serial schedule, a transaction does
not start execution until the currently
running transaction finished execution
Serial Vs Interleaved Schedules
Interleaved Schedule
◦ Multiple users can access databases—and use computer
systems—simultaneously because of the concept of
multiprogramming, which allows the operating system of the
computer to execute multiple programs—or processes—at the
same time.
◦ Central processing unit (CPU) can only execute at most one
process at a time. However, multiprogramming operating
systems execute some commands from one process, then
suspend that process and execute some commands from the
next process, and so on. A process is resumed at the point
where it was suspended whenever it gets its turn to use the
CPU again. This process is called Interleaved Scheduling
 Interleaved Processing Vs Parallel Processing

If the computer system has multiple hardware processors (CPUs), parallel processing of multiple processes is
possible, as illustrated by processes C and D in Figure 20.1. Most of the theory concerning concurrency control
in databases is developed in terms of interleaved concurrency
Concurrency Issues

◦ Several problems can occur when concurrent transactions execute in an uncontrolled manner.
◦ The Lost Update Problem
◦ The Temporary Update (or Dirty Read) Problem
◦ The Incorrect Summary Problem
◦ The Unrepeatable Read Problem
The Lost Update

The final value of item X is incorrect because T2 reads the value of X before T1 changes it in the
database, and hence the updated value resulting from T1 is lost
 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.
The 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.
The Unrepeatable Read Problem
◦ Another problem that may occur is called unrepeatable read, where a transaction T reads the
same item twice and the item is changed by another transaction T′ between the two reads.
Serializability
Assumptions
Conflicting Instructions
Method 1: Conflict Serializability
Example 1 Conflict Equivalent Schedule
Example 2
 Method 2: View Serializability

Initial Read

Intermediate
Read

Final Write
 A B
Example View Serializable Initial Read T1 T1
Final Write T2 T2
T1 T2 T1 T2 Intermediate Read T2 T2
R(A) R(A) After After
w(A) W(B)
W(A) W(A)
R(A) R(B)
S
W(A) W(B)
R(B) R(A) A B
W(B) W(A) Initial Read T1 T1
R(B) R(B) Final Write T2 T2
W(B) W(B) Intermediate Read T2 T2
After After
S S1 w(A) W(B)

So S is View Serializable to S1
S1
Check if a schedule is Conflict serializable.
• Check Conflict Pairs in Other transactions and draw Edges
T1 T2 T3
R(X)
R(Y) T1 T2
R(X)
R(Y)
R(Z)
W(Y)
W(Z) T3
R(Z)
W(X) Precedence Graph is Acyclic
W(Z) So this Schedule is Conflict Serializable
What is the Equivalent Serial Schedule?
◦ Remove the vertex with Indegree = 0
◦ First T2 is removed along with its edges
Possible Schedules are 3!
◦ T3 has in degree=0 So next T3 will be removed
Order of the Serial Schedule
T2, T3, T1

T1 T2 T1

T1

T3 T3
Test For view Serializability
Recoverability

◦ we have studied schedules while assuming implicitly that there are no transaction failures. We
now address the effect of transaction failures during concurrent execution.
◦ If a transaction Ti fails, for whatever reason, we need to undo the effect of this
transaction to ensure the atomicity property of the transaction. In a system that allows
concurrent execution, the atomicity property requires that any transaction Tj that is
dependent on Ti (that is, Tj has read data written by Ti) is also aborted. To achieve
this, we need to place restrictions on the type of schedules permitted in the system.
Example : Irrecoverable Schedule
Notice that T7 commits immediately after executing
the read(A) instruction. Thus, T7 commits while T6
is still in the active state. Now suppose that T6 fails
before it commits. T7 has read the value of data item
A written by T6. Therefore, we say that T7 is
dependent on T6. Because of this, we must abort T7
to ensure atomicity.
However, T7 has already committed and cannot be
aborted. Thus, we have a situation where it is
impossible to recover correctly from the failure of
T6.
Recoverable Schedules
◦ A recoverable schedule is one where, 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 commit operation of Tj .
◦ For the example of schedule 9 to be recoverable, T7 would have to delay committing until after T6
commits
Cascading Rollback
Cascade less Schedule

◦ It is desirable to restrict the schedules to those

where cascading rollbacks cannot occur. Such
schedules are called cascadeless schedules.
Formally, a cascadeless schedule is one
where, 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 . It is
easy to verify that every cascadeless schedule
Commit
is also recoverable.
Commit