Database Concurrency

Concurrency Control
Most DBMS are multi-user systems.
Many transactions - at the same time.
Databases shared!

• Problem– in a multiuser environment,

simultaneous access to data can result in
interference and data loss
• Solution–Concurrency Control
– 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
 Concurrency Control
The concurrent execution of many different
transactions submitted by various users must be
organized such that transactions do not interfere
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.
 Concurrency Control
• Concurrency control is important because the
simultaneous execution of transactions over a
shared database can create several data
integrity and consistency problems.
• The three main problems are
1. Lost updates
2.Uncommitted dependency problem
3.Inconsistent retrievals.
 Example:
let’s examine a simple PRODUCT table.
• One of the PRODUCT table’s attributes is a
product’s quantity on hand (PROD _QOH).
• Assume that you have a product whose
current PROD_QOH value is 35.
• Also assume that two concurrent transactions,
T1 and T2, occur that update the PROD_QOH
value for some item in the PRODUCT table.
 Two Concurrent Transactions to Update Quantity

Transaction Computation

T 1: Purchase 100 units PROD _QOH= PROD _QOH + 100

T2: Sell 30 units PROD _QOH= PROD_QOH − 30

 Serial execution of transactions under
normal circumstances NO ERROR!!!

Time Transactio Step Stored Value

n
1 T1 Read PROD_QOH 35

2 T1 PROD_QOH=35 + 100

3 T1 Write PROD_QOH 135

4 T2 Read PROD _QOH 135

5 T2 PROD _QOH = 135 − 30

6 T2 Write PROD_QOH 105

 1. Problem of Lost Update
• But suppose that a transaction is able to read a
product’s PROD_QOH value from the table be fore a
previous transaction has been committed
Time Transaction Step Stored Value

1 T1 Read PROD _QOH 35

2 T2 Read PROD _QOH 35
3 T1 PROD _QOH = 35 +100
4 T2 PROD _QOH=35 - 30
5 T1 Write PROD _QOH 135
(Lost update)
6 T2 Write PROD _QOH 5
 Lost Update (Contd)
• The lost update problem occurs when two
concurrent transactions, T1 and T2, are
updating the same data element and one of
the updates is lost (overwritten by the other
transaction).
• An apparently successfully completed update
operation by one user can be overridden by
another user.
Example 2 (lost update)
 2. Uncommitted dependency problem
• The uncommitted dependency problem occurs
when one transaction is allowed to see the
intermediate results of another transaction
before it has committed.
– T1 and T2, are executed concurrently and the first
transaction (T1) is rolled back after the second
transaction (T2) has already accessed the
uncommitted data
– thus violating the isolation property of transactions.
 uncommitted dependency
Problem(Contd.)
Time Transaction Step Stored
Value
1 T1 Read PROD_QOH 35
2 T1 PROD_QOH= 35 + 100
3 T1 Write PROD_QOH 135
4 T2 Read PROD_QOH 135
(Read uncommitted
data)
5 T2 PROD_QOH= 135 - 30
6 T1 ***ROLLBACK*** 35
7 T2 Write PROD_QOH 105
 3. Inconsistent retrievals
• The problem of inconsistent retrievals occur
when a transaction reads several values from
the database, but a second transaction
updates some of them during the execution of
the first.
 Inconsistent Retrievals(contd.)
To illustrate inconsistent retrievals problem, assume the following
conditions:
1. T1 calculates the total quantity on hand of the products stored in
the PRODUCT table.
2. At the same time, T2 updates the quantity on hand (PROD_QOH) for
two of the PRODUCT table’s products.
Retrieval During Updates
Transaction T1 Transaction T2
SELECT SUM(PROD _QOH) UPDATE PRODUCT
FROM PRODUCT SET PROD _QOH= PROD _QOH + 10
WHERE PROD _CODE= ’1546-QQ2’
UPDATE PRODUCT
SET PROD _QOH= PROD _QOH − 10
WHERE PROD _CODE= ’1558-QW1’
Commit
 T2 represents the correction of a typing error: the user added
10 units to product 1558-QW1’s PROD_QOH but meant to add
the 10 units to product 1546-QQ2’s PROD _QOH.
To correct the problem the user
• adds 10 to product 1546-QQ2’s PROD_QOH and
• subtracts 10 from product 1558 -QW1’s PROD_QOH.

BEFORE AFTER
PROD_CODE PROD_QOH PROD_QOH
11QER/31 8 8
13-Q2/P2 32 32
1546-QQ2 15 (15 + 10) 25
1558-QW1 23 (23 – 10) 13
2232-QTY 8 8
2232-QWE 6 6
Total 92 92
 Transac Action Valu Total
Tim tion Inconsistent Retrievals e
e

1 T1 Read PROD _QOH for PROD 8 8

_CODE= ' 11QER/31’
2 T1 Read PROD_QOH for PROD 32 40
_CODE= ' 13-Q2/P2'
3 T2 Read PROD_QOH for PROD 15
_CODE= ' 1546-QQ2'
4 T2 PROD_QOH=15+10
5 T2 Write PROD _QOH for PROD 25
_CODE= ' 1546-QQ2'
6 T1 Read PROD_QOH for PROD _COD 25 AFTER(6
E= '1546-QQ2' 5)
CONCURRENCY CONTROL
TECHNIQUES
 Currency Control Techniques
• Pessimistic approach
– the system assumes the worst
– it assumes that two or more users will want to
update the same record at the same time
– Example: Locking
• Optimistic approach
– assumes that although conflicts are possible, they
will be very rare.
– Example : Versioning
 Locking Mechanisms
• Any data that are retrieved by a user for updating
must be locked, or denied to other users, until the
update is completed or aborted
• No other user can perform update until unlocked
• The most common way of achieving serialization
 Types of Locks
• The database administrator can generally
choose between two types of locks
1.Shared Locks
(also called S locks or read locks)
2.Exclusive locks
(also called X locks or write locks)
 Shared locks (S locks or read lock)
• Shared locks allow other transactions to read (
but not update) a record or other resource.
• A transaction should place a shared lock on a
record or data resource when it only read and
not update that record
• Placing a shared lock on a record prevents
another user from placing an exclusive lock,
but not a shared lock on that record.
Exclusive lock( X lock or write lock)
• Exclusive locks prevents another transaction
from reading (and therefore updating) a
record until it is unlocked.
• A transaction should place an exclusive lock
on a record when it is about to update that
record.
• Placing an exclusive lock on a record prevents
another user from placing any type of lock on
the record.
 Locking level/granularity
• Lock granularity indicates the level of lock use.
Locking can take place at the following levels:
1.Database level
2.Table level
3.Page level
4.Row level
5.field (attribute) level
 1. Database Level locking
• The entire database is locked and becomes
unavailable to other users.
– preventing the use of any tables in the database
by transaction T2 while transaction Tl is being
executed.
• This level has limited application, such as
during a backup of the entire database.
Database level locking
 2. Table level locking
• The entire table containing a requested record
is locked.
• Appropriate for bulk updates that will update
the entire table
– Giving all employees a 5 percent raise
Table level locking
 3. Block or page level locking
• The physical storage block(page) containing a
requested record is locked.
• A page will be a fixed size(4k,8k etc) and may
contain records of more than one type.
• Most commonly implemented level.
Page level locking
 4. Record level locking
• Only the requested record(or row) is locked.
• All other records, even within the table, are
available to other users.
• Overhead at run time when several records
are involved in an update
Record level locking
 5. Field level locking
• Only the particular field or (column) in a
requested .
• Appropriate when most updates affect only one
or two fields in a record.
– e.g. in inventory control applications the quantity on
hand field changes frequently, but other fields( such
as description etc) are rarely updated.
• Require considerable overhead and are rarely
used.
 Deadlock

John and Marsha will wait

forever for each other to
release their locked resources!
 How a Deadlock condition is created
TIME TRANSACTI REPLY LOCK STATUS
ON
0 Data X
D
Data Y
E
1 T1 : OK UNLOCKED A
LOCK(X) UNLOCKED
D
2 T2 : OK LOCKED L
LOCK(Y) UNLOCKEDO
3 T1 : WAIT LOCKED C
LOCK(Y) LOCKED K
4 T2 : WAIT LOCKED
 Deadlock
• An impasse that results when two or more
transactions have locked a common resource,
and each waits for the other to unlock that
resource. OR
• Deadlock is a situation in which two or more
transactions are waiting for one another to give
up locks
• There are two methods to deals with infinite
locking
1. Deadlock prevention
2. Deadlock resolution
 Deadlock Prevention
• Deadlock prevention aims to avoid the
occurrences of deadlocks
• Example:
– Two-phase locking
 Two-phase Locking
• Two phase locking locks all the records required
at the beginning of the transaction.
The two phases are :
1. A growing phase, in which a transaction
acquires all required locks without unlocking any
data. Once all locks have been acquired, the
transaction is in its locked point.
2 . A shrinking phase, in which a transaction
releases all locks and cannot obtain any new lock.
 Two-phase Locking (contd.)
• In figure (shown on previous slide), the
transaction acquires all of the locks it needs until
it reaches its locked point . (In this example, the
transaction requires two locks.)
• When the locked point is reached, the data are
modified to conform to the transaction’s
requirements.
• Finally, the transaction is completed as it releases
all of the locks it acquired in the first phase.
 Two-phase Locking (contd.)
• Unfortunately, it is often difficult to predict in
advance that what records will be required to
process a transaction.
• As a result, deadlock prevention is not always
practical
 Deadlocks resolution
• Deadlock resolution first allows deadlocks to
occur. Then using certain technique, the
deadlock is detected and resolved.
• The DBMS should have a module to do this
task. The deadlock detection algorithm will be
invoked at different points in time depending
on the frequency of the occurrence of
deadlock.
 Deadlock Resolution(contd.)
• The resource usage details is stored in the form of matrix
by keeping the users(subjects) on rows and
resources(data items/records known as objects) on
columns
• Before using a particular resource by a user, a program
will scan through the respective column and find
whether that particular resource being locked by some
other user.
• Also, the program will check whether the next
immediate resource required by the other user is same
as the resource currently used by the present user.
• If so, one of the two users will be asked to roll back his
transaction
 Versioning(Optimistic Approach)
• Optimistic approach to concurrency control
• Instead of locking
• Assumption is that simultaneous updates will
be infrequent
• Each transaction can attempt an update as it
wishes
• The system will reject an update when it
senses a conflict
• Use of rollback and commit for this
• Using an optimistic approach, each
transaction moves through two or three
phases, referred to as read , validation, and
write
• The optimistic approach is acceptable for
most read or query database systems that
require few update transactions.
 Read Phase
• During the read phase , the transaction reads
the database, executes the needed
computations, and makes the updates to a
private copy of the database values. All
update operations of the transaction are
recorded in a temporary update file, which is
not accessed by the remaining transactions.
 Validation Phase
• During the validation phase, the transaction is
validated to ensure that the changes made
will not affect the integrity and consistency of
the database. If the validation test is positive,
the transaction goes to the write phase. If the
validation test is negative, the transaction is
restarted and the changes are discarded .
 Write Phase
• During the write phase, the changes are
permanently applied to the database.
• The validation phase examines the reads and
writes of transactions that may cause
interference.
– Each transaction T is assigned a timestamp at the
start of its execution, Start(T)
– One at the start of its validation phase,
Validation(T)
– One at its finish time, Finish(T) (including its write
phase, if any).
• To pass the validation test, one of the following must be
true:
1. All transactions S with earlier timestamps must have
finished before transaction T started; that is, Finish(S) <
Start(T)
2. If transaction T starts before an earlier one S finishes, then:
a) The set of data items written by the earlier transaction
are not the ones read by the current transaction, and
b) The earlier transaction completes its write phase
before the current transaction enters its validation
phase; that is, Start(T) < Finish(S) < Validation(T).
• Rule 2(a) guarantees that the writes of the
earlier transaction are not read by the current
transaction
• Rule 2(b) guarantees that the writes are done
serially, ensuring no conflict.