Chapter 3

Concurrency Control Techniques

1
 Outline
• Introduction
• Concurrency control techniques
– Locking techniques
– Timestamp ordering techniques
– Multi version concurrency control techniques

2
 Introduction
•Concurrency control is the activity coordinating
concurrent accesses to a database in a multi-
user database management system (DBMS).
• During concurrent access to the data item
three problems will occur
1. The lost update problem
2. The temporary update (dirty read) problem
3. Incorrect summary problem

3
 The Lost Update
• This problem occurs when two transactions that
access the same database items have their
operations interleaved in a way that makes the
value of some database items incorrect.
• Suppose that transactions T1 and T2 are
submitted at approximately the same time, and
• suppose that their operations are interleaved as
shown in Figure

4
Cont’d

5
 Lost Update Problem
time T1 T2
read_item(X);
X:=X - N;
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
write_item(X);
Y:=Y + N;
write_item(Y);
6
 Temporary Update or Dirty Read
• This problem occurs when one transaction
updates a database item and then the transaction
fails for some reason Meanwhile, the updated item
is accessed (read) by another transaction before it
is changed back (or rolled back) to its original value
Example
• T1 fails and it should change the value back to old
X value (T1s write occurred but its Txn failed)
• T2 read incorrect value as T1 was not complete

7
Cont’d

8
 Temporary Update (Dirty Read)
time T1 T2
read_item(X);
X:=X - N;
write_item(X);
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
T1 fails and aborts
9
 The Incorrect Summary
• 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 update

10
 Cont’d
time T1 T2
sum:=0;
read_item(X); read_item(A);
X:=X-N; sum:=sum+A;
write_item(X);

read_item(X);
sum:=sum+X;
read_item(Y); read_item(Y);
Y=Y+N
sum:=sum+Y
Write_item(Y)

11
 Types of Failures.
• Failures are generally classified as transaction,
system, and media failures.
 A computer failure (system crash).
 A hardware, software, or network error occurs
 A transaction or system error.
 Some operation in the transaction may cause it to
fail, such as integer overflow or division by zero
 Local errors or exception conditions detected by
the transaction.
 certain conditions may occur that necessitate
cancellation of the transaction data for Txn missing,
insufficient account balance
12
 Concurrency Control Techniques
Categories of concurrency techniques
1.Locking techniques
2.Timestamp ordering techniques
3.Multi-version concurrency control techniques
4.Optimistic concurrency control techniques

13
 Concurrency Control Using Locks
• Lock
– A variable associated with a data item
– Describes status of the data item with respect
to operations that can be performed on it
• Types of locks
– Binary locks
– Shared/Exclusive locks or Read/Write lock

14
 Cont’d
• Locking is an operation which secures
– Permission to read
– Permission to write a data item for a Txn
– Ex. Lock(X). data item X is locked on behalf of Txn
• Unlocking is an operation which removes
these permissions from the data item
– Ex. Unlock(X). data item X is made available for all
other Txns
– Lock and Unlock are atomic operations

15
 Binary Locks

• Can have Two states (values)

– Locked (1)
• Item cannot be accessed

– Unlocked (0)
• Item can be accessed when requested

16
 Shared/exclusive or read/write locks

• Read operations on the same item are not

conflicting
• Must have exclusive lock to write
• Three locking operations
– read_lock(X)
– write_lock(X)
– unlock(X)

17
 Locking Rules
If the simple binary locking scheme described here is used, every
transaction(T) must obey the following rules:
1. T must issue read_lock(X) or write_lock(X) before any
read_item(X) operation is performed in T
2. T must issue write_lock(X) before any write_item(X) operation is
performed in T
3. T must issue unlock(X) after all read_item(X) and write_item(X)
operations are completed in T
4. T will not issue a read_lock(X) if it already holds a read lock or
write lock on X (may be relaxed)
5. T will not issue a write_lock(X) if it already holds a read lock or
write lock on X (may be relaxed)
6. T will not issue unlock (X) request unless it holds a read lock write
lock on X

18
 Cont’d
• These rules can be enforced by the lock
manager module of the DBMS.
• Between the lock_item(X) and unlock_item(X)
operations in transaction T, T is said to hold
the lock on item X.
• At most one transaction can hold the lock on a
particular item.
• Thus no two transactions can access the same
item concurrently.
19
 Conversion of Locks
• A transaction T that holds a lock on item X,
under certain conditions, is allowed to convert
the lock from one state to another
– Upgrade
• Issue a read_lock operation then a write_lock operation
• Convert read_lock to write_lock
– Downgrade
• Issue a write_lock operation then a read_lock operation
• Convert write_lock to read_lock

20
 Two-Phase Locking (2PL) Protocol

• Transaction is said to follow the two-phase-

locking protocol if all locking operations

(read_lock, write_lock ) precede the first

unlock operation

21
 Cont’d

Transactions T1 and T2 do not follow the two-phase locking protocol because the
write_lock(X) operation follows the unlock(Y) operation in T1, and similarly the
write_lock(Y) operation follows the unlock(X) operation in T2.

22
 2PL Example

• Both T1’ and T2’ follow the 2PL protocol

• Any schedule including T1’ and T2’ is guaranteed to be serializable
• Limits the amount of concurrency

23
 Cont’d

1. Basic 2PL
All lock operations before the first unlock operation
2. Conservative 2PL or static 2PL
Lock all the items it accesses before the transaction
begins execution.
• Deadlock free protocol
• Read-set and write-set of the transaction should be
known

24
 Cont’d
3. Strict 2PL
No exclusive lock will be unlocked until the
transaction commits or aborts
– Strict 2PL guarantees strict schedules
4. Rigorous 2PL
No lock will be unlocked until the transaction
commits or aborts

25
Dealing with Deadlocks and Starvation
in 2PL
• 2PL can produce deadlocks and starvation
• Deadlock
– Deadlock occurs when each transaction T in a set of
two or more transactions is waiting for some item that
is locked by some other transaction T’ in the set.
– Both transactions stuck in a waiting queue
• Starvation
– Occurs if a transaction cannot proceed for an indefinite
period of time while other transactions continue
normally.
– Unfair waiting scheme
– Solution: first-come-first-served queue

26
Cont’d

27
 Cont’d
• Deadlock prevention protocols
– Conservative 2PL, lock all needed items in advance
– Ordering all items in the database
• Transaction that needs several items will lock them in that
order
• Possible actions if a transaction is involved in a
possible deadlock situation
– Block and wait
– Abort and restart
– Preempt and abort another transaction
28
 Cont’d
• Two schemes that prevent deadlock and do not
require timestamps
– No waiting algorithm
• If transaction unable to obtain a lock, immediately
aborted and restarted after a certain time delay
– Cautious waiting algorithm
• If a transaction holding the lock is not waiting for
another item to be locked then allow T to wait otherwise
abort and restart T
• Deadlock-free

29
 Deadlock detection and timeouts

• Victim selection
– Deciding which transaction to abort in case of
deadlock
• Timeouts
– If system waits longer than a predefined time, it
aborts the transaction

30
 Concurrency Control Based on Timestamp Ordering

• Timestamp
– Unique identifier assigned by the DBMS to
identify a transaction
– Assigned in the order submitted
– Transaction start time
• Concurrency control techniques based on
timestamps do not use locks
– Deadlocks cannot occur

31
 Cont’d

• Generating timestamps
– Counter incremented each time its value is
assigned to a transaction

– Current date/time value of the system clock

• Ensure no two timestamps are generated during the
same tick of the clock

32
 Cont’d
• Timestamp ordering (TO)
– Allows interleaving of transaction operations
– Must ensure timestamp order is followed for each pair
of conflicting operations
• Each database item assigned two timestamp
values
– read_TS(X)
• The largest timestamp among all the timestamps of
transactions that have successfully read item X
– write_TS(X)
• The largest timestamp among all the timestamps of
transactions that have successfully written item X

33
 Cont’d

• Timestamp Ordering (TO) algorithms

– Basic timestamp ordering

– Strict timestamp ordering

– Thomas’s write rule

34
 Multiversion Concurrency
Control Techniques
• Several versions of an item are kept by a
system
• Some read operations that would be rejected in
• other techniques can be accepted by reading an
older version of the item
– Maintains serializability
• Multiversion currency control scheme types
– Based on timestamp ordering
– Based on two-phase locking
35
 Cont’d
• Multiversion technique based on timestamp ordering
– Two timestamps associated with each version are kept
• read_TS(Xi)
• write_TS(Xi)
• Whenever a transaction T is allowed to execute a
write_item(X) operation, a new version of item X is
created, with both the write_TS and the read_TS set to
TS(T). Correspondingly, when a transaction T is
allowed to read the value of version Xi, the value of
read_TS() is set to the larger of the current read_TS()
and TS(T).

36
 Cont’d
• Multiversion two-phase locking using certify
locks
• Three locking modes: read, write, and certify
• Hence, the state of LOCK(X) for an item X
can be one of read-locked, write-locked,
certify-locked, or unlocked.

37
Concurrency Control Based on Validation (Optimistic) Techniques

• Also called validation or certification techniques

• No checking is done while the transaction is
executing
• Updates not applied directly to the database until
finished transaction is validated
– All updates applied to local copies of data items
• Validation phase checks whether any of
transaction’s updates violate serializability
– Transaction committed or aborted based on result
38
 Cont’d
• There are three phases for Optimistic concurrency control
protocol:
1. Read phase: A transaction can read values of committed
data items from the database. However, updates are applied
only to local copies (versions) of the data items kept in the
transaction workspace.
2. Validation phase: Checking is performed to ensure that
serializability will not be violated if the transaction updates
are applied to the database.
3. Write phase: If the validation phase is successful, the
transaction updates are applied to the database; otherwise,
the updates are discarded and the transaction is restarted

39