CONCURRENCY CONTROL

By the end of this presentation you will be

able to:
-Define what concurrency control is
-Identify and explain the problems associated
with lack of concurrency control
-Describe the concurrency control algorithms
CONCURRENCY CONTROL (CC)
– Most DBMS are multi-user systems run with the
expectation that users will be able to share data
contained in the database
– If users are only reading data no data integrity
problems will be encountered because no changes
will be made in the database. However if one or
more users are updating data then potential
problems with maintaining data integrity arise
– The concurrent execution of many different
transactions submitted by various users must be
organised such that each transaction does not
interfere with another transaction with one
another in a way that produces incorrect results.
– The concurrent execution of transactions must be
such that each transaction appears to execute in
isolation thus enforcing serializability (where it
seems as if the transactions are being performed
one after the other) in a multi-user database
environment
– The objective of CC is to maximise transaction
throughput while preventing interference among
multiple users
CONCURRENCY CONTROL DEFINED
Concurrency control is defined as:

i) The coordination of simultaneous transaction execution in a

multiprocessing database system
ii) It is the process of managing simultaneous operations against a
database so that data integrity is maintained and the
operations do not interfere with each other in a multi-user
environment
Lack of Concurrency Control can create data integrity and
consistency problems which include:
– Lost Update Problem
– Uncommitted Data Problem
– Inconsistent Retrievals Problem
 Lost Update Problem
Tim Jack’s Trans Jill’s Trans Balance
e
T1 Begin
T2 Read Balance Begin 1000
T3 Read Balance 1000
T4 Bal = Bal – 50 1000
(950)
T5 Write Bal (950) Bal = Bal + 100 950
(1100)
T6 Commit 950
T7 Write Bal (1100) 1100
 Uncommitted Data Problem
Tim Deposit Interest Bal
e
T1 Begin Transaction 1000
T2 Read Bal (1000) 1000
T3 Bal = Bal + 1000 1000
(2000)
T4 Write Bal (2000) Begin Transaction 2000
T5 Read Bal (2000) 2000
T6 Bal = Bal*1.05 2000
(2100)
T7 Rollback 1000
T8 Write Bal (2100) 2100
 Inconsistent Retrievals Problem
Time SumBal Transfer Bal A Bal B Bal C Sum
T1 Begin Trans 5000 5000 5000
T2 Sum = 0 Begin Trans 5000 5000 5000
T3 Read BalA (5000) 5000 5000 5000
T4 Sum = Sum + Read BalA (5000) 5000 5000 5000
BalA (5000)
T5 Read BalB (5000) BalA = BalA -1000 (4000) 5000 5000 5000
T6 Sum = Sum+BalB Write BalA (4000) 4000 5000 5000
(10000)
T7 Read BalC 4000 5000 5000
T8 BalC =BalC + 1000 (6000) 4000 5000 5000
T9 Write BalC (6000) 4000 5000 6000
T10 Read BalC Commit 4000 5000 6000
T11 Sum=Sum + BalC 4000 5000 6000
(16000)
T12 Write Sum (16000) 4000 5000 6000 16000
T13 Commit 4000 5000 6000 16000
CONCURRENCY CONTROL ALGORITHMS
There are 2 basic approaches to concurrency control:
i) A pessimistic approach ( which always assumes the
worst); it assumes that every time transactions
execute chances of them accessing and changing
the same data items is very high so it automatically
implements some control to prevent this from
happening.
ii) An optimistic approach- which assumes that
chances of transactions colliding and accessing and
changing the same data items is slim so it will only
deal with conflicts only and when they occur.
PESSIMISTIC APPROACH
LOCKING- it involves the use of locks on a
database item to prevent other transactions
from performing conflicting actions on the
same item
- With locking any data that is retrieved by a
user for updating must be locked or denied to
other users until the update is complete or
aborted so other users must wait if they are
trying to obtain a conflicting lock on the same
part of the database
 EXAMPLE OF LOCKING MECHANISM
TIME JACK’S JILL’S BALANCE
TRANSACTION TRANSACTION
T1 BEGIN
TRANSACTION
T2 READ BAL BEGIN 1000
TRANSACTION
T3 LOCK BAL : 1000
T4 BAL=BAL-50 : 950
T5 WRITE BAL : 950
T6 COMMIT : 950
T7 UNLOCK BAL : 950
T8 LOCK BAL 950
T9 BAL = BAL+100 1050
T10 WRITE BAL 1050
T11 COMMIT 1050
T12 UNLOCK BAL 1050
Concurrency is affected by two things i.e. the type
of the lock and the granularity of the lock
There are two types of locks:
i) Shared (S) or read lock- which must be obtained before
reading a database item; the technique allows other
transactions to read but not update a record or other
resource( it prevents another user from placing an
exclusive lock on that record)
ii) Exclusive (X) or write lock- which must be obtained
before writing a database item; the technique prevents
other transactions from reading and therefore updating
a record until it is unlocked
 EXAMPLE OF HOW SHARED AND
EXCLUSIVE LOCKS ARE USED
TIME JACK’S TRANSACTION JILL’S TRANSACTION
T1 BEGIN TRANSACTION
T2 PLACE READ LOCK BEGIN TRANSACTION
T3 READ BAL PLACE READ LOCK
T4 BAL=BAL-50 READ BAL
T5 REQUEST WRITE LOCK BAL = BAL + 100
T6 : REQUEST WRITE LOCK
T7 : :
T8 (WAIT) :
T9 : (WAIT)

JACK INTIATES HIS TRANSACTION, THE PROGRAM PLACES A READ LOCK ON HIS RECORD SINCE
HE IS READING THE RECORD TO CHECK THE ACCOUNT BALANCE. WHEN HE REQUESTS A
WITHDRAWAL THE PROGRAM ATTEMPTS TO PLACE A WRITE LOCK. HOWEVER JILL HAD
ALREADY PLACED A SHARED LOCK ON THE RECORD. AS A RESULT HIS REQUEST IS DENIED
SINCE IF A RECORD HAS A READ LOCK ANOTHER USER CANNOT OBTAIN A WRITE LOCK
 LOCKING LEVEL (GRANULARITY)
This is the extent of the database resource that
is included with each lock; locks are
implemented at the following levels:
Database- entire database is locked and becomes unavailable to other users
Table- entire table containing a requested record is locked; this level is appropriate
mainly for bulk updates such giving all employees a 5% raise
Block or page- the physical storage block(or page) containing a requested record is
locked
Record- only the requested record or row is locked; all other records are available to
other users
Field- only the particular field or column in a requested record is locked; this level is
appropriate when the updates affect only one or two fields in a records e.g you
want to update price column
 PROBLEMS ASSOCIATED WITH
LOCKING
As much as locking ensures that transactions do
not collide it results in deadlocks which is an
impasse that results when two or more
transactions have locked a common resource
and each waits for the other to unlock that
resource
Deadlock may be avoided using either deadlock
prevention or deadlock resolution
 DEADLOCK PREVENTION
This is used when the user programs must lock
all records they will require at the beginning of a
transaction
Two Phase locking protocol is used in this case.
It has 2 phases:
i) Growing phase- where all the necessary
locks are acquired
ii) Shrinking phase- where locks are released
 DEADLOCK RESOLUTION
It allows deadlocks to occur but builds mechanisms into
the DBMS for detecting and breaking the deadlocks
The DBMS maintains a matrix of resource usage which at
a given instant indicates what users (subjects) are using
what resources (objects); by scanning the matrix the
computer can detect deadlocks as they occur; it then
resolves the deadlocks by “backing up” one of the
deadlocks as they occur; any changes made by that
transaction up to the time of deadlock are removed and
the transaction is restarted when the required resources
become available
 OPTIMISTIC APPROACH:
VERSIONING
• There is no form of locking but each transaction is
restricted to a view of the database as of the time
that the transaction started and when a transaction
modifies a record the DBMS creates a new record
version instead of overwriting the old record
• In cases of a conflict, changes made by one of the
users are updated in this case since they are time
stamped the earlier transaction is given priority; the
other user’s transaction is aborted or rolled back
 EXAMPLE OF VERSIONING
TIME JACK’S TRANSACTION JILL’S TRANSACTION
T1 BEGIN TRANSACTION
T2 READ BAL BEGIN TRANSACTION
T3 READ BAL
T4 BAL = BAL-50 BAL = BAL+100
T5 WRITE BAL WRITE BAL
T6 COMMIT ROLL BACK
T7 RESTART TRANSACTION
T8
T9