CHAPTER III

CONCURRENCY CONTROL
Concurrency Control
 The management of simultaneous
execution of many different application
programs such that each transaction
does not interfere with another
transaction.
 The concurrent execution of transactions
must be such that each transaction
appears to execute in isolation.
 Recall ACID properties!!!
Conditions Necessary for Conflict

 Two operations trying to access same

data item.
 Two operations are from different
transactions.
 At least one of them is a write operation.
Problems of Concurrency

 The concurrent execution of transactions

may lead, if uncontrolled, to problems
such as an inconsistent database.
 Concurrency control techniques are
used to ensure that multiple transactions
submitted by various users do not
interfere with one another in a way that
produces incorrect results.
Read and Write Operations of a
Transaction
 read_item(X): reads a database item named X
into a program variable also named X.
Execution of the command includes the
following steps:
 find the address of the disk block that contains item
X
 copy that disk block into a buffer in the main
memory
 copy item X from the buffer to the program variable
named X
Read and Write Operations of a
Transaction
 write_item(X): writes the value of program
variable X into the database item named X.
Execution of the command includes the following
steps:
 find the address of the disk block that contains item X
 copy that disk block into a buffer in the main memory
 copy item X from the program variable named X into
its current location in the buffer
 store the updated block in the buffer back to disk (this
step updates the database on disk)
Problems due to the Concurrent
Execution of Transactions
 The Lost Update Problem
 The Temporary Update (uncommitted
dependency) Problem or dirty read.
 The Incorrect Summary (inconsistent
analysis) Problem.
The Lost Update Problem
 Two transactions accessing the same database item have their
operations interleaved in a way that a completed update by one user
ends up being overwritten by another user.
T1: T2:
read_item(X);
X:= X - N;
time read_item(X);
X:= X + M; item X has
write_item(X); incorrect value
read_item(Y); because its update
from T1 is lost
write_item(X);
Y:= Y + N;
write_item(Y);
If transactions T1 and T2 are submitted at approximately the
same time and their operations are interleaved then the value of
database item X will be incorrect because T2 reads the value of
X before T1 changes it in the database and hence the updated
database value resulting from T1 is lost.
The Temporary Update Problem
 One transaction updates a database item and then the
transaction -for some reason- fails. The updated item is
accessed by another transaction before it is changed back to
its original value.
T1: T2:
read_item(X);
X:= X - N;
write_item(X);
read_item(X);
time X:= X - N;

write_item(X);
read_item(Y);

transaction T1 fails and must change the

value of X back to its old value; meanwhile T2
has read the "temporary" incorrect value of X
The Incorrect Summary Problem
 One transaction is calculating an aggregate summary function on a
number of records while other transactions are updating some of
these records. The aggregate function may calculate some values
before they are updated and others after.

T1: T3:
sum:= 0;
read_item(A);
sum:= sum +
A;
.
read_item(X); . T3 reads X after N
X:= X - N; . is subtracted and
write_item(X);
read_item(X); reads Y before N is
sum:= sum + added, so a wrong
X; summary is the
read_item(Y);
sum:= sum + result
Y;
read_item(Y);
Y:= Y + N;
write_item(Y);
Isolation

 Isolation is used to refer to what might

loosely be described as the degree of
interference that a given transaction is
prepared to tolerate.
 The isolation property ensures that each
transaction appears to execute in
independence from other transactions.
Isolation Levels

 There are four levels of isolation:

 Read uncommitted
 Read committed

 Repeatable read

 Serializable

 Each is defined in terms of three

phenomena that are either permitted or
not at a given isolation level.
Dirty read

 Means you're permitted to read

uncommitted, or dirty, data. You can
achieve this effect by just opening a DB
file that someone else is writing and
reading whatever data happens to be
there. Data integrity is compromised,
foreign keys are violated, and unique
constraints are ignored.
Non-repeatable read

 This simply means that if you read a row

at time T1 and try to reread that row at
time T2, the row may have changed. It
may have disappeared, it may have
been updated, and so on.
Phantom read

 This means that if you execute a query

at time T1 and re-execute it at time T2,
additional rows may have been added to
the database, which may affect your
results. This differs from a non-
repeatable read in that with a phantom
read, data you already read hasn't been
changed, but instead, more data
satisfies your query criteria than before.
Read uncommitted-Dirty read
 The READ UNCOMMITTED isolation level
allows dirty reads. A transaction T1 may read
the update of a transaction T2 which has not
yet committed. If T2 fails and is aborted then
T1 would have read a value that doesn’t exist
and is incorrect.
 Dirty read doesn’t place any locks on rows
fetched during a select statement.
 As a result dirty read isolation offers the best
performance of all isolation levels.
Read committed
 The READ COMMITTED isolation level states
that a transaction may read only data that has
been committed in the database. There are no
dirty reads (reads of uncommitted data). There
may be non-repeatable reads (that is, rereads
of the same row may return a different answer
in the same transaction) and phantom reads
(that is, newly inserted and committed rows
become visible to a query that weren't visible
earlier in the transaction).
Repeatable Read

 The goal of REPEATABLE READ is to

provide an isolation level that gives
consistent, correct answers and prevents
lost updates. The results of a given
query must be correct with respect to
some point in time.
 With RR the DB locks all rows examined
for the duration of the transaction.
Serializable
 This is generally considered the most
restrictive level of transaction isolation, but it
provides the highest degree of isolation.
 A SERIALIZABLE transaction operates in an
environment that makes it appear as if there
are no other users modifying data in the
database. Any row you read is assured to be
the same upon a reread, and any query you
execute is guaranteed to return the same
results for the life of a transaction.
 Least support for concurrency.
Summary
Isolation Level Dirty Read Non-repeatable Read Phantom Read

READ
UNCOMMITT Permitted Permitted Permitted
ED
READ
No Permitted Permitted
COMMITTED

REPEATABLE
No No Permitted
READ

SERIALIZABLE No No
No
Schedules
A schedule S of n transactions is a sequential
ordering of the operations of the n
transactions.
 A schedule maintains the order of operations
within the individual transaction. It is subject to
the constraint that for each transaction T
participating in S, if operation i is performed in
T before operation j, then operation i will be
performed before operation j in S.
Serial, Non-serial and Serializable
Schedules
A schedule S is serial if, for every
transaction T participating in S all of T's
operations are executed consecutively in
the schedule; otherwise it is called non-
serial (interleaved).
 A schedule S of n transactions is
serializable if it is equivalent to some
serial schedule of the same n
transactions.
Example of Serial Schedules
Schedule A

T1: T2:
read_item(x)
X:= X - N;
write_item(X);
read_item(Y);
time Y:=Y + N;
write_item(Y);

read_item(X);
X:= X +
M;

write_item(X);
Advantages & Disadvantages

 Correctness always guaranteed coz

there’s no interference
 Poor resource utilization – no
concurrency.
Example of Non-serial
Schedules
Schedule A

T1: T2:
read_item(X);

X:= X - N;

read_item(X);
time
X:= X +
M;
write_item(X);
read_item(Y);

write_item(X);
Y:=Y + N;
write_item(Y);
Serializability
A serializable schedule S is a non-serial
schedule with n transactions T1,T2….Tn whose
execution gives the same result as a serial
execution of the same n transactions.
 Basic Assumption:
 Each transaction preserves database consistency.
 Serial execution preserves consistency
A schedule is serializable if it is equivalent to a
serial schedule of the same n transactions.
 When are schedules equivalent? Two
definitions:
 Conflict Equivalence
 View Equivalence
Conflict Equivalence

 Two schedules are conflict equivalent if

the order of any two conflicting
operations is the same in both schedules
i.e. they belong to different txns, they
access same data item and at least one
of the two op. is a write.
 Understand that changing the order of
conflicting operations in the two txns will
give totally different results in the DB
Conflict Serializability
A schedule S is conflict serializable iff
it is conflict equivalent to some serial
schedule S`.
In such a case we can reorder the
non- conflicting operations in S until
we form the equivalent serial
schedule S`
Example 1
T1 T2

Read(A)
Write(A)

Read(B) Non-
Write(B) conflicting
Read(A) operations
Write(A) swapped
Serial
Read(B) schedule
Write(B) T1-T2
Example 2
Consider two schedules A & B:

T1 T2 T1 T2
Read(X); Read(X);
X=X-N; X=X-N;
Write(X); Write(X);
Read(Y);
Y=Y+N; Read(X);
write(Y); X=X+M;
Write(X);
Read(X);
X=X+M; Read(Y);
Write(X); Y=Y+N;
write(Y);

A B
Example 2
 According to the definition, schedule B is
equivalent to serial schedule A, since in both
schedules read(X) of T2 reads the value of X
written by T1.
 Also T1 is the last transaction to write Y and
T2 is the last transaction to write X in both
schedules.
 Now notice that read(Y) and and write(Y) of T1
in schedule B doesn’t conflict with read(X) and
write(X) of T2 so we can swap. Hop its clear!!
Testing for conflict serializability.
 Use a directed or precedence graph:
 Create a node labeled Ti for each transaction
participating in a schedule.
 If Tj executes a read-item(X) after Ti executes a
write-item(X), create an edge from Ti to Tj
 If Tj executes write-item(X) after Ti executes a
read-item(X), create an edge Ti to Tj
 If Tj executes write-item(X) after Ti executes a
write-item(X), create an edge Ti to Tj
 S is serializable iff the graph has no cycles
Example

Schedule A
T1: T2:
read_item(X);
X:= X - N;
write_item(X);
time read_item(Y);
Y:=Y + N;
write_item(Y);

read_item(X);
X:= X + M;

write_item(X);

T1 T2 precedence graph for

schedule A (serial)
X
Example
Schedule A
T1: T2:
read_item(X);
X:= X - N;

read_item(X);
X:= X + M;
time write_item(X);
read_item(Y);

write_item(X);
Y:=Y + N;
write_item(Y);
X

precedence graph for

T1 T2 schedule A (nonserial)

X
Example (Schedule A)
T1 T2 T3 T4 T5
read(X)
read(Y)
read(Z)
read(V)
read(W)
read(W)
read(Y)
write(Y)
write(Z)
read(U)
read(Y)
write(Y)
read(Z)
write(Z)
read(U)
write(U)
Precedence Graph for Schedule
A

T1 T2

T4
T3
Test 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 precedence graph is acyclic, the serializability
order can be obtained by a topological sorting of
the graph nodes. This is a linear order consistent
with the partial order of the graph.
For example, a serializability order for Schedule A
would be
T T T T T .
Consider the following schedule,
S:
T1 T2 T3

Read Y

Read Z

Read X

Write X

Write Y

Write Z

Read Z

Read Y

Write Y

Read Y

Write Y
Is S serializable?

 Soln:
X,Y S is serializable.
T1 T2
Possible serial schedules are:

Y T1 T2 T3
Z,Y
T3 T1 T2
T3
T3 T2 T1
Excersises
 Consider three transactions T1,T2,T3 and
schedules S1 and S2 below:
 T1 : r1(x),r1(z),w1(x)
 T2 : r2(z),r2(y),w2(z),w2(y)

 T3 : r3(x),r3(y),w3(y)

 S1:
r1(x),r2(z),r1(z),r3(x),r3(y),w1(x),w3(y),r2(y),
w2(z),w2(z)
 S2:
r1(x),r2(z),r3(x),r1(z),r2(y),r3(y),w1(x),w2(z),
w3(y),w2(y)
Excersises

 Required:
 Draw the precedence graph for S1 and
S2 and state whether each schedule is
serializable or not. If yes write the
equivalent serial schedule.
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, where Q is
a data item and Ti is a transaction:
1. If Ti reads the initial value of Q in schedule S, then Ti
must, in schedule S´, also read the initial value of Q
2. If Ti executes read(Q) in schedule S, and that value was
produced by transaction Tj (if any), then transaction Ti
must in schedule S´ also read the value of Q that was
produced by transaction Tj
3. The transaction (if any) that performs the final write(Q)
operation in schedule S (for any data item Q) must
perform the final write(Q) operation in schedule S´
View Equivalence
 The idea behind view equivalence is that
as long as each read operation of a
transaction reads the result of the same
write operation in both schedules(both
have same set of txns) then the write
operation of each txn must produce the
same results.
 The read operations are hence said to
see the same view in both schedules.
View Serializability

 View serializability says that a particular

ordering of instructions in a schedule S
is view equivalent to a serial ordering S'
iff:
 Every value read in S is the same value that
was read by the same read in S'.
 The final write of every object is done by the

same transaction in both schedules.

 Each transaction "views" the same values.
View Serializability
 A schedule S is view serializable it is view equivalent to a serial
schedule
 Every conflict serializable schedule is also view serializable

 The schedule above is view serializable since it is view

equivalent to a serial schedule <T3, T4, T6>.why?
 Every view serializable schedule may be not conflict serializable.
View serializable schedule has blind writes.(value written by an
op. indept of its old value read from the DB.)
View Serializability

 Every conflict serializable schedule is

view serializable however the converse
is not always true.
 Consider above example.Discuss
Recoverability of schedules

A recoverable schedule is one that once

a transaction T has committed it is not
necessary to rollback T.
 A schedule S is recoverable if no
transaction T in S commits until all
transactions T` that have written an item
that T reads are committed.
Example
 The following schedule is not recoverable if T9 commits
immediately after the read

 If T8 should abort or rollback, T9 would have read (and

possibly shown/committed to the user) an incorrect
database state, this results in a situation where it is
impossible to recover from the failure of T8 .
Recoverability (Cont.d)

 Cascading rollback – a single

transaction failure leads to a series of
transaction rollbacks of transactions that
were dependent on the failed
transaction. Consider the following
schedule where none of the transactions
has yet committed.
Example

If T10 fails, T11 and T12 must also be rolled

back.
Can lead to the undoing of a significant
amount of work
This problem can be addressed by
ensuring that transactions read from
committed transactions.
Recoverability (Cont.d)
 Cascadeless schedules — cascading rollbacks cannot
occur; 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 (why?)
 It is desirable to restrict schedules to those that are
cascadeless.
 Strict Schedule – requires that a txn neither reads nor
writes an item until the last txn that wrote it has
committed. Strict schedules are cascadeless by default.