SE (CS)

Spring Semester 2023

Database Management Systems

(CS-222)

Lecture #24-25
Concurrency Controls

Dr Syed Zaffar Qasim

Assistant Professor (CIS)
1

CONCURRENT EXECUTIONS

▪ Concurrency: Simultaneous or interleaved execution

of transactions in a database system.
▪ The concurrent systems are in fact multi-user
computer systems.
▪ Two good reasons (or benefits) for allowing
concurrency:-
1. Increased Throughput
2. Reduced Average Response Time

CS-222: Database Management Systems 1

 Benefits of Concurrency
1.Increased Throughput
o Throughput: the number of transactions that can be
executed in a unit time.
o How concurrency is possible?
❖A transaction consists of multiple steps.
❖Some involve I/O activity; others involve CPU
activity.
❖The CPU and the disks in a computer system can
operate in parallel.
❖Therefore, I/O activity can be done in parallel with
processing at the CPU.
3

Benefits of Concurrency

1.Increased Throughput (cont’d)

o While a read or write on behalf of one transaction is in
progress on one disk,
❖another transaction can be running in the CPU,
❖while another disk may be executing a read or write
on behalf of a third transaction.
o In this way, the operations of the transactions are
interleaved to achieve concurrent execution.
o Thereby, there is an increase in the throughput of the
system.
4

CS-222: Database Management Systems 2

 Benefits of Concurrency
1.Increased Throughput (cont’d)
o Correspondingly, the processor and the disk
utilization also increase;
o In other words, the processor and disk spend less
time idle or not performing any useful work.
2.Reduced Average Response Time
o Response Time: elapsed time between the
submission of a request until the response begins to
appear as output.
o There may be a mix of transactions running on a
system, some short and some long.

Benefits of Concurrency

2.Reduced Average Response Time (cont’d)

o If transactions are run serially,
❖a short transaction may have to wait for a
preceding long transaction to complete,
❖which can lead to unpredictable delays in running
a transaction.
o If the transactions are operating on different parts of
the database,
❖it is better to let them run concurrently,
❖sharing the CPU cycles and disk accesses among
them.
6

CS-222: Database Management Systems 3

 Benefits of Concurrency

2.Reduced Average Response Time (cont’d)

▪ Concurrent execution reduces the unpredictable
delays in running transactions.
▪ Moreover, it also reduces the average response time.
▪ The motivation for using concurrent execution in a
database
o essentially the same as the motivation for using
multiprogramming in an operating system,
o which allows two or more programs (or
transactions) to execute at the same time.
7

Problems of Concurrency
▪ Concurrent access is relatively easy if all users are only
reading data, as there is no way that they can interfere
with one another.
▪ However, when two or more users are accessing the
database simultaneously and
o at least one is updating data,
o there may be interference that can result in
inconsistencies.
▪ However, although two transactions may be perfectly
correct in themselves,
o the uncontrolled interleaving of operations in this way
may produce an incorrect result,
o thus compromising the integrity and consistency of the
database. 8

CS-222: Database Management Systems 4

 Concurrency Control

▪ The process of managing simultaneous operations on

the database without having them interfere with one
another.
▪ Essentially three ways in which things can go
wrong.
o three ways that a transaction though correct in
itself,
o can nevertheless produce the wrong answer if
some other transaction interferes with it in some
way.

Problems of Concurrency

▪ The three problems are

1. The lost update problem
2. The uncommitted dependency problem and
3. The inconsistent analysis problem
▪ To illustrate these problems, we use a simple bank
account relation that contains the customer’s
account balances.
▪ In this context, we are using the transaction as the
unit of concurrency control.
10

CS-222: Database Management Systems 5

 The lost update problem
▪ An apparently successfully completed update operation by
one user can be overridden by another user.
▪ The problem is illustrated in Figure 1 in which
transaction T1 is executing concurrently with
transaction T2.
▪ T1 is withdrawing an amount of 10 from an account in
tuple x with balance balx, initially 100, and T2 is
depositing amount 100 into the same account.
▪ If these transactions are executed serially,
o one after the other with no interleaving of
operations,
o the final balance would be Rs 190 no matter which
transaction is performed first.
11

The lost update problem

▪ Transactions T1 and T2 start at nearly the same
time, and both read the balance as 100.
▪ T2 increases balx by 100 to 200 and stores the
update in the database.
▪ Meanwhile, transaction T1 decrements its copy of
balx by 10 to 90 and
o stores this value in the database, overwriting the
previous update, and
o thereby losing the amount 100 previously added
to the balance.
▪ The loss of T2’s update is avoided by preventing T1
from reading the value of balx until after T2’s
update has been completed.
12

CS-222: Database Management Systems 6

 The lost update problem

Time T1 T2 BALx
t1 100
Begin Transaction
t2 read(balx) 100
Begin Transaction
t3 read(balx) 100
balx = balx + 100 100
t4
(balx  200)
balx = balx – 10 100
t5
(balx  90)
t6 write(balx) 200
t7 commit 200
t8 write(balx) 90
Fig 1 t9 commit 90
13

The uncommitted dependency (or dirty read) problem

▪ The uncommitted dependency problem occurs when one
transaction is allowed to see the intermediate results of
another transaction before it has committed.
▪ Fig 2 shows an example of an uncommitted
dependency that causes an error, using the same initial
value for balance balx as the previous example.
▪ Here, transaction T4 updates balx to 200, but it aborts
the transaction so that balx should be restored to its
original value of 100.
▪ However, by this time transaction T3 has read the new
value of balx (200) and is using this value as the basis
of the 10 reduction, giving a new incorrect balance of
190, instead of 90.
14

CS-222: Database Management Systems 7

 The uncommitted dependency (or dirty read) problem

▪ The value of balx read by T3 is called dirty data, giving

rise to the alternative name, the dirty read problem.
▪ The reason for the rollback is unimportant; it may be
that the transaction was in error, perhaps crediting the
wrong account.
▪ The effect is the assumption by T3 that T4’s update
completed successfully, although the update was
subsequently rolled back.
▪ This problem is avoided by preventing T3 from
reading balx until after the decision has been made to
either commit or abort T4’s effects.
15

The uncommitted dependency (or dirty read) problem

Time T3 T4 BALx
t1 100
Begin Transaction
t2 read(balx) 100
t3 balx = balx + 100 100
t4 write(balx) 200
Begin Transaction
⋮
t5 read(balx) 200
t6 rollback 100
t7 balx = balx - 10 100
t8 write(balx) 190
Fig 2 t9 commit 190
16

CS-222: Database Management Systems 8

 Problems of Concurrency

▪ The two problems in these examples concentrate

on transactions that are updating the database and
their interference may corrupt the database.
▪ However, transactions that only read the database
o can also produce inaccurate results
o if they are allowed to read partial results of
incomplete transactions
o that are simultaneously updating the database.
▪ We illustrate this with the next example.

17

The Inconsistent Analysis problem

▪ The problem of inconsistent analysis occurs when a
transaction reads several values from the database but a
second transaction updates some of them during the
execution of the first.
▪ For example, a transaction that is summarizing
data in a database (for example, totaling balances)
o will obtain inaccurate results if,
o while it is executing, other transactions are
updating the database.
• One example is illustrated in Figure 3, in which a
summary transaction TB is executing concurrently
with transaction TA.
18

CS-222: Database Management Systems 9

 The Inconsistent Analysis problem

▪ Transaction TB is totaling the balances of tuple x

(100), tuple y (50), and tuple z (25).
▪ However, in the meantime, transaction TA has
transferred 10 from balz to balx, so that TB now has
the wrong result (10 too low).
▪ We say that TB has seen an inconsistent state of the
database and has therefore performed an
inconsistent analysis.
▪ This problem is avoided by preventing transaction
TB from reading balx and balz until after TA has
completed its updates.
19

The Inconsistent Analysis problem

Time TA TB BALx BALy BALz sum
t1 100 50 25
Begin Transaction
t2 sum = 0 100 50 25 0
t3 read(balx) 100 50 25 0
t4 sum = sum + balx 100 50 25 100
t5 read(baly) 100 50 25 100
t6 sum = sum + baly 100 50 25 150
Begin Transaction 100 50 25 150
t7 read(balz) 100 50 25 150
t8 balz = balz – 10 100 50 25 150
t9 write(balz) 100 50 15 150
t10 read(balx) 100 50 15 150
t11 balx = balx + 10 100 50 15 150
t12 write(balx) 110 50 15 150
t13 commit 110 50 15 150
t14 read(balz) 110 50 15 150
t15 sum = sum + balz 110 50 15 165
Fig t16 commit 110 50 15 165 20
3

CS-222: Database Management Systems 10

 LOCKING
▪ A concurrency control technique.
▪ The basic idea is simple: When a transaction accesses
(read or write) an object, it acquires a lock on that
object.
▪ The effect of the lock is to prevent other transactions from
accessing that object as long as the lock is in effect.
▪ The first transaction is therefore able to carry out its
processing
o in the certain knowledge that the object in question
will remain in a stable state
o for as long as that transaction wishes it to.

21

LOCKING

1. First, we assume the system supports two types

of locks,
a) Exclusive locks (X locks) and
b) Shared locks (S locks).
o Note: X and S locks are sometimes called write
locks and read locks, respectively.
o We also assume until further notice that tuples
are the only kind of lockable object.

22

CS-222: Database Management Systems 11

 LOCKING

2.If transaction A holds an exclusive (X) lock on

tuple t, then a request from some distinct
transaction B for a lock of either type on t will be
denied.
3. If transaction A holds a shared (S) lock on tuple t,
then request from some distinct transaction B for
an X lock on t will be denied;
o A request from some distinct transaction B for
an S lock on t will be granted (that is, B will now
also hold an S lock on t).
23

LOCKING
▪ These rules can conveniently be summarized by means
of a lock type compatibility matrix (Fig. 4).
▪ Matrix is interpreted as follows: Consider some tuple t.
Transaction A
X S –
Transaction B

X N N Y
S N Y Y Fig 4
– Y Y Y
▪ Suppose transaction A currently holds a lock on t as
indicated by the entries in the column headings (dash =
no lock);
o and suppose some distinct transaction B issues a
request for a lock on t as indicated by the entries down
the left-hand side. 24

CS-222: Database Management Systems 12

 LOCKING
▪ An N indicates a conflict (B's request cannot be satisfied
and B goes into a wait state), a Y indicates compatibility
(B's request is satisfied).
▪ The matrix is obviously Symmetric.
Transaction A
X S –

Transaction B
X N N Y
S N Y Y
– Y Y Y

▪ Next we introduce a Data Access Protocol (or Locking

Protocol) that makes use of X and S locks to guarantee
that problems such as those described in earlier cannot
occur. 25

Data Access (or locking) Protocol

1. A transaction that wishes to retrieve a tuple must

first acquire an S lock on that tuple.
2. A transaction that wishes to update a tuple must
first acquire an X lock on that tuple.
o Alternatively, if it already holds an S lock on the
tuple (as it will in a RETRIEVE-UPDATE
sequence), then it must promote that S lock to X
level.

26

CS-222: Database Management Systems 13

 Data Access (or locking) Protocol
▪ Note: Transaction requests for tuple locks are
normally implicit:
o a tuple retrieve request is an implicit request for
an S lock and a
o tuple update request is an implicit request for an X
lock on the relevant tuple.
▪ Also, of course, we take the term update to include
INSERTs and DELETEs as well as UPDATEs per se,
o but the rules require some minor refinement to
take care of INSERTs and DELETEs.
27

Data Access (or locking) Protocol

3. If a lock request from transaction B is denied
because it conflicts with a lock already held by
transaction A, transaction B goes into a wait state.
o B will wait until A’s lock is released.
o Note: The system must guarantee that B does
not wait forever (a possibility sometimes
referred to as livelock).
o A simple way to provide such a guarantee is to
service all lock requests on a first-come, first-
served basis.
4. X locks are held until end-of-transaction
(COMMIT or ROLLBACK). S locks are normally
held until that time also. 28

CS-222: Database Management Systems 14

 Solving the three concurrency problems

29

Preventing the lost update problem with

locking protocol
Time T1 T2 BALx
t1 100
Begin Transaction
X_lock(tuple x)
t2
read(balx) 100
Begin Transaction
t3 X_lock(tuple x) 100
balx = balx + 100 100
t4 wait
(balx  200)
t5 wait write(balx) 200
t6 wait commit/unlock(balx) 200
t7 read(balx) 200
balx = balx – 10 200
(balx  190)
t8 write(balx) 190
t9 commit/unlock(balx) 190 30

CS-222: Database Management Systems 15

 Preventing the uncommitted dependency
problem with locking protocol
Time T3 T4 BALx
t1 100
Begin Transaction
X_lock(tuple x)
t2
read(balx) 100
t3 balx = balx + 100 100
t4 write(balx) 200
Begin Transaction
X_lock(tuple x) ⋮ 200
t5
wait
t6 wait rollback/unlock(tuple x) 100
t7 read(balx) 100
t8 balx = balx – 10 100
t9 write(balx) 90
t10 commit/unlock(tuple x) 90

31

Preventing the inconsistent analysis problem with locking protocol

Time TA TB BALx BALy BALz sum
t1 100 50 25
Begin Transaction
t2 sum = 0 100 50 25 0
S_lock(tuple x)
t3
read(balx) 100 50 25 0
t4 sum = sum + balx 100 50 25 100
S_lock(tuple y)
t5
read(baly) 100 50 25 100
t6 sum = sum + baly 100 50 25 150
Begin Transaction 100 50 25 100
X_lock(tuple z) 50 25 100
t7 100
read(balz)
t8 balz = balz – 10 100 50 25 100
t9 write(balz) 100 50 15 150
t10 X_lock(tuple x) 100 50 15 150
t11 wait S_lock(tuple z) 100 50 15 150
t12 wait wait 100 50 15 150
32
t13 wait wait 100 50 15 150

CS-222: Database Management Systems 16