Chapter 1.

b
Concurrency Control Techniques
 Concurrency Control Techniques
Concurrency control techniques are those techniques used to ensure the
isolation property of concurrently executing transactions.
Most of the techniques ensure serializability of schedules by using protocols
that guarantees serializability.
Some of the main techniques used to control concurrent execution of
transactions are
1. Concurrency Control Based on Locking.
2. Concurrency Control Based on Timestamp Ordering.
3. Multi version Concurrency Control Techniques
4. Optimistic Concurrency Control Techniques
 1. Concurrency Control Based on Locking

 A lock is a variable associated with a data item that describes the status
of the item with respect to possible operations that can be applied to it.
 One lock with each data item in the database.
 Locks are used to synchronize(coordinate) the access to the data item.
 A lock guarantees exclusive use of a data item to a current transaction.
 A transaction acquires a lock prior to data access and the lock is released
(unlocked) when the transaction is completed.
 So that another transaction can lock the data item for its exclusive use.
 Cont’d.
 The use of locks based on the assumption that conflict between
transactions is likely to occur is often referred to as pessimistic
locking.
 Most multiuser DBMSs automatically initiate and enforce locking
procedures.
 All lock information is managed by a lock manager, which is
responsible for assigning and controlling the locks used by the
transactions.
 Lock 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

 In a database-level lock, the entire database is locked.

 Thus preventing the use of any tables in the database by
transaction T2 while transaction Tl is being executed.
 This level of locking is unsuitable for multiuser DBMSs.
 Data access will be very s-l-o-w.
Cont’d
 2. Table Level
 In a table-level lock, the entire table is locked,
 Preventing access to any row by transaction T2 while
transaction T1 is using the table. T2 must wait until
T1 unlocks the table.
 If a transaction requires access to several tables, each
table may be locked.
 However, two transactions can access the same
database as long as they access different tables.
 Cont’d
 Table-level locks are less restrictive than database-
level locks.
 But it also cause traffic jams when many transactions
are waiting to access the same table.
 Table-level locks are not suitable for multiuser
DBMSs.
Cont’d
 3. Page Level

 In a page-level lock, the DBMS will lock an entire disk page.

 A disk page, or page, is the equivalent of a disk block, which can
be described as a directly addressable section of a disk.
 A table can span several pages, and a page can contain several
rows of one or more tables.
 Page-level locks are currently the most frequently used
multiuser DBMS locking method.
Cont’d
 4. Row Level
 A row-level lock is much less restrictive than the locks discussed
earlier.
 The DBMS allows concurrent transactions to access different rows
of the same table even when the rows are located on the same page.
 This approach improves the availability of data
 However, its management requires high overhead because a lock
exists for each row in a table of the database involved in a
conflicting transaction.
Row Level
 5. Field Level

 The field-level lock allows concurrent transactions to access

the same row as long as they require the use of different fields
(attributes) within that row.
 It is the most flexible multiuser data access
 Nevertheless, it is rarely implemented in a DBMS because it
requires an extremely high level of computer overhead and
the row-level lock is much more useful in practice.
 Types of Lock

 Regardless of the level of locking, the DBMS may use different

lock types those are
1. Binary or
2. Shared/Exclusive
 1. Binary Lock
 A binary lock has only two states/values: locked (1) or unlocked (0).
 Every database operation requires that the affected object be locked.
 If an object is locked by a transaction, no other transaction can use
that object.
 If an object is unlocked, any transaction can lock the object for its
use.
 As a rule, a transaction must unlock the object after its
termination.
 Cont’d
 Two operations, lock_item and unlock_item, are used with binary locking.
 A transaction requests access to an item X by first issuing a lock_item (X)
operation.
 If LOCK(X) =1, the transaction is forced to wait.
 If LOCK(X) =0, it is set to 1 and the transaction is allowed to access item X.
 When the transaction completed using the item, it issues an unlock_item(X)
operation, which sets LOCK(X) back to 0 (unlocks the item) so that X may be
accessed by other transactions.
 Cont’d
 Hence, a binary lock enforces mutual exclusion on the data item
 Lock and unlock features eliminate the lost update problem because the lock
is not released until the WRITE statement is completed.

 Binary locks are too restrictive to yield optimal concurrency conditions

 Therefore, it is not used much in practice.

 For example, the DBMS will not allow two transactions to read the same
database object even though both transactions not update the database.
 2. Shared/Exclusive Locks (Read/Write Locks)

 The labels “shared” and “exclusive” indicate the nature of the lock.
 An exclusive lock exists when access is reserved specifically for the
transaction that locked the object.
 The exclusive lock must be used when the potential for conflict exists.
 A shared lock exists when concurrent transactions are granted read
access on the basis of a common lock.
 A shared lock produces no conflict as long as all the concurrent
transactions are read-only.
 Cont’d
 Multiple-mode lock.
 There are three locking operations: read_lock(X), write_lock(X),
and unlock(X).
 A lock associated with an item X, LOCK(X), now has three
possible states: read-locked, write-locked or unlocked.
 A read-locked item is also called share-locked because other
transactions are allowed to read the item
 A write-locked item is called exclusive-locked because a single
transaction exclusively holds the lock on the item.
 Cont’d

 A shared lock is issued when a transaction wants to read data from the
database and no exclusive lock is held on that data item.
 An exclusive lock is issued when a transaction wants to update (write) a
data item and no locks are currently held on that data item by any other
transaction.
 Shared locks allow several read transactions to read the same data item
concurrently.
 The exclusive lock is granted if and only if no other locks are held on the
data item.
 This condition is known as the mutual exclusive rule: only one transaction
at a time can own an exclusive lock on the same object.
 Cont’d

 Although the use of shared locks renders data access more

efficient, a shared/exclusive lock schema increases the lock
manager’s overhead, for several reasons:
1. The type of lock held must be known before a lock can be
granted.
2. Three lock operations exist: READ_LOCK, WRITE_LOCK, and
UNLOCK
3. It allow a lock upgrade (from shared to exclusive) and a lock
downgrade (from exclusive to shared).
 Conversion of Locks

A Transaction is allowed under certain conditions to convert the lock from one
state to another.
• Upgrading:
– Convert the lock from shared to exclusive by issuing write lock(X) after
its read lock(X).
– The transaction must be the only one that has the read lock or it must
wait.
• Downgrading:
– Convert the lock from exclusive to shared by issuing read_lock(X) after
the write_lock(X).
 Cont’d

Locks prevent data inconsistencies, but they can lead to two major
problems:
1. The resulting transaction schedule might not be serializable.
2. The schedule might create deadlocks. (A deadlock occurs when
two transactions wait indefinitely for each other to unlock data. )
To solve the above mentioned issues additional protocols concerning the
positioning of locking and unlocking operations are followed in every
transaction.
 Two-Phase Locking (2PL) to Ensure Serializability

Two-phase locking defines how transactions acquire and relinquish (release)

locks.
Two-phase locking guarantees serializability.
 A transaction is said to follow the 2PL protocol if all locking operations
precede the first unlock operation of the transaction.
 The transaction is divided into two phases:
 Growing or Expanding phase (first phase) where new locks can be
issued and none can be released. Once all locks have been acquired, the
transaction is in its locked point.
 Shrinking phase (second phase) where existing locks can be released and
cannot obtain any new lock.
 Two-Phase Locking (2PL) to Ensure Serializability

 Example

Without 2PL With 2PL

T1 T2 T1 T2
read_lock(Y); read_lock(X); read_lock(Y); read_lock(X);
read_item(Y); read_item(X); read_item(Y); read_item(X);
unlock(Y); unlock(X); write_lock(X); write_lock(Y);
write_lock(X); write_lock(Y); unlock(Y); unlock(X);
read_item(X); read_item(Y); read_item(X);
X:=X+Y; Y:=X+Y; X:=X+Y; read_item(Y);
write_item(X); write_item(Y); write_item(X); Y:=X+Y;
unlock(X): unlock(Y); unlock(X): write_item(Y);
unlock(Y);
 Two-Phase Locking (2PL) to Ensure Serializability

 2PL limits the concurrency.

• A transaction T may not be able to release an item X even after it is through
using it but needs to lock another item later.
• Another transaction that needs X has to wait even though T is done with X.
 The algorithm is called the Basic 2PL and there are many variations to it:
 Conservative 2PL
 Strict 2PL
 Rigorous 2PL
 Conservative/Static 2PL
 It requires a transaction to lock all the items it accesses before the
transaction begins execution (by pre-declaring its read and write sets).
 The read-set of a transaction is the set of all items that the transaction
reads and
 The write-set is the set of all items that it writes.
 If any of the pre-declared items needed cannot be locked, the transaction
does not lock any item; instead, it waits until all the items are available
for locking.
 It is difficult in practice because it is not possible in most cases to get
the read and write sets.
 The conservative 2PL is a deadlock-free protocol.
 Strict 2PL

 It is the most popular variation of 2PL in practice.

 It requires that a transaction T does not release any of its
exclusive locks until it commits or aborts.
 Strict 2PL is not a deadlock-free protocol.
 Rigorous 2PL

 It is a more restrictive variation of Strict 2PL.

 It requires that a transaction T does not release any of its locks
(shared or exclusive) until it commits or aborts.
 It is easier to be implemented than the strict 2PL.
 Deadlocks
 A deadlock occurs when two transactions wait indefinitely for each
other to unlock data.
 For example, a deadlock occurs when two transactions, T1 and T2,
exist in the following mode
 T1 = access data items X and need Y
 T2 = access data items Y and need X
Note that deadlocks are possible only when one of the transactions
wants to obtain an exclusive lock on a data item
No deadlock condition can exist among shared locks.
Deadlocks
 2. Concurrency Control Based on Timestamp Ordering

Timestamp of transaction T, TS(T) is a unique identifier created by the

DBMS to identify a transaction.
 Timestamp values are assigned in the order in which the transactions are
submitted to the system.
So a timestamp can be thought of as the transaction start time.
A larger timestamp value indicates a more recent event or operation.
Concurrency control techniques based on timestamp ordering do not use
locks; hence, deadlocks cannot occur.
 Cont’d

Timestamps can be generated in two ways

 Using a counter timestamp
 Using date timestamps
 Timestamp Ordering Algorithm(TO)

 It is used to order the transactions based on their timestamps.

If Wa(x) and Rb(x) are conflicting operations, of Ta and Tb for item x,
then Wa(x) is processed before Rb(x) if and only if TS (Ta) < TS (Tb).
The TO algorithm associates with each database item X have two
timestamp (TS) values.
Those are RTS(X) and WTS(X).
 Cont’d
1. RTS(X): The read timestamp of item X, which is the largest
timestamp among all the timestamps of transactions that have
successfully read item X.

 RTS(X) = TS(T), where T is the youngest/last transaction that has

read X successfully.

2. WTS(X): The write timestamp of item X, which is the largest of all

the timestamps of transactions that have successfully written item X.

 WTS(X) = TS(T), where T is the youngest/last transaction that has

written X successfully.
 Cont’d

There are two common timestamp ordering algorithm those are:-

A. Basic Timestamp Ordering
B. Strict Timestamp Ordering
 A. Basic Timestamp Ordering (TO)

 Utilizes Timestamps to guarantee serializability of concurrent

transactions.

 Whenever some transaction T tries to issue a read_item(X) or a

write_item(X) operation, the basic TO algorithm compares the
timestamp of T with RTS(X) and WTS(X) to ensure that the
timestamp order of transaction execution is not violated.
 Cont’d
 The concurrency control algorithm must check whether conflicting
operations violate the timestamp ordering in the following two
cases:
 Case 1 (Read): Transaction T issues a read(X) operation

o If TS(T) < WTS(X), then read(X) is rejected (as the TO rule is violated).

 [then a younger transaction has already written to the data item so abort and
roll-back T and reject the operation.]
o If WTS(X) <= TS(T), then execute read(X) of T and update RTS(X) to the
largest of TS(T).
 Cont’d
 Case 2 (Write): Transaction T issues a write(X) operation

o If TS(T) < RTS(X) or if TS(T) < WTS(X), then write is rejected.

 [then a younger/last transaction has already read/write the data item so

abort and roll-back T and reject the operation.]

o If RTS(X) <= TS(T) and WTS(X) <= TS(T), then execute write(X) of T
and update WTS(X) to TS(T).
 Basic TO Algorithm Example
 Two transactions T1 and T2. Initially RTS=0 and WTS=0 for data items X, Y
 Timestamps are as follows: TS(T1)=10 and TS(T2)=20
T1 T2
TS(T1)=10 TS(T2)=20
1. A1 = Read(X)
2. A1 = A1 – k
3. Write(X, A1)
1. A1 = Read(X)
2. A1 = A1 * 1.01
3. Write(X, A1)
4. A2 = Read(Y)
5. A2 = A2 + k
6. Write(Y, A2)
4. A2 = Read(Y)
5. A2 = A2 * 1.01
6. Write(Y, A2)

 Discuss whether the following schedule is serializable or not? Justify your

 Cont’d.
T1(10) T2(20)
RTS(X) : 10 1. A1 = Read(X)
WTS(X) : 10 2. A1 = A1 – k
RTS(Y) : 0 3. Write(X, A1)
WTS(Y) : 0 1. A1 = Read(X) RTS(X) : 20
2. A1 = A1* 1.01 WTS(X) : 20
3. Write(X, A1) RTS(Y) : 0
WTS(Y) : 0

RTS(X) : 20 4. A2 = Read(Y)
WTS(X) : 20 5. A2 = A2 + k
RTS(Y) : 10 6. Write(Y, A2)
WTS(Y) : 10 4. A2 = Read(Y) RTS(X) : 20
5. A2 = A2 * 1.01 WTS(X) : 20
6. Write(Y, A2) RTS(Y) : 20
WTS(Y) : 20
The schedule given above is serializable
 Example 2
 Discuss whether the following schedule is serializable or not? Justify your
answer using Basic TO Algorithm.
T1 T2
TS(T1)=10 TS(T2)=20
1. A1 = Read(X)
2. A1 = A1 – k
3. Write(X, A1)
1. A1 = Read(X)
2. A1 = A1* 1.01
3. Write(X, A1)
4. A2 = Read(Y)
5. A2 = A2 * 1.01
6. Write(Y, A2)
4. A2 = Read(Y)
5. A2 = A2 + k
6. Write(Y, A2)
 Cont’d

Advantages of Basic TO Algorithm

 Schedules are serializable (like 2PL protocols)

 No waiting for transaction, thus, no deadlocks!

 Cont’d

Disadvantages of Basic TO Algorithm

 Schedule may not be recoverable (read uncommitted data)

o Solution: Utilize Strict TO Algorithm.

 Starvation is possible (if the same transaction is continually

aborted and restarted)

o Solution: Assign new timestamp for aborted transaction

 B. Strict Timestamp Ordering
The Basic T.O. algorithm guarantees serializability but not
Recoverability.

The Strict Timestamp Ordering algorithm introduces recoverability.

Strict Schedule: A transaction can neither read nor write an

uncommitted data item X.

Strict Timestamp Ordering: Extend the accept cases of the Basic

Timestamp Ordering algorithm by adding the requirement that a commit
occurs before T proceeds with its operation. i.e.,
 Strict Timestamp Ordering

Case 1: Transaction T issues a read(X) operation:

 If WTS(X) < TS(T), then delay T until the transaction T’ that wrote
X has terminated (committed or aborted).
 Strict Timestamp Ordering

Case 2: Transaction T issues a write(X) operation:

 If RTS(X) <= TS(T) and WTS(X) <= TS(T), then delay T until the
transaction T’ that wrote and read X has terminated (committed or
aborted).
 3. Multi version Concurrency Control (MVCC)

When a MVCC database needs to update an item of data, it will not

overwrite the old data with new data, but instead mark the old data as
obsolete/outdated and add the newer version elsewhere.
Thus there are multiple versions stored, but only one is the latest.
This approach maintains a number of versions of a data item and
allocates the right version to a read operation of a transaction.
 Cont’d
 Unlike other mechanisms a read operation in this mechanism is never
rejected.

 When any transaction writes an item it writes a new version and the
old version of the item is retained.

 When any transaction reads an item, appropriate version has to be

provided maintaining serializability.

Disadvantage
 More storage (RAM and Disk) is required to maintain multiple versions.
 Multi version technique based on timestamp ordering

Assume X1, X2, …, Xn are the version of a data item X created by a write
operation of transactions.

 Note: New version of Xi is created only by a write operation.

 With each Xi a RTS (read timestamp) and a WTS (write timestamp) are
associated.

 RTS(Xi): The read timestamp of Xi is the largest of all the timestamps of

transactions that have successfully read version Xi .

 WTS(Xi): The write timestamp of Xi is the largest of all the timestamps of

transactions that have successfully written the value of version X i.
 Cont’d
 Basic Idea: Works much like Basic TO with the difference that instead of
WTS(X) and RTS(X) we now utilize the highest WTS(Xi) and highest
RTS(Xi) respectively.

 Whenever a transaction T is allowed to execute a write_item(X) operation, a

new version Xk+1 of item X is created, with

 WTS(Xk+1) = TS(T).

 RTS(Xk+1) = TS(T).

 When a transaction T is allowed to read the value of version X k, the value of

RTS(X ) = largest of the current RTS(X ) and TS(T).
 Cont’d

To ensure serializability, the following rules are used

 If transaction T issues read(X), find the version i of X that has the

highest WTS(Xi) of all versions of X that is also less than or equal to
TS(T),

 Then accept the read and update the RTS(X) respectively.

 Cont’d

 If transaction T issues write(X) and highest WTS(Xi) also less than

or equal to TS(T), and highest RTS(Xi) less than or equal to TS(T),
then create a new version Xi and RTS(Xi )= WTS(Xi) = TS(T).
 4. Optimistic Concurrency Control ordering

 In optimistic concurrency control techniques no checking is done

while the transaction is executing.

 In Optimistic Concurrency Control, a schedule is checked against

serializability only at the time of commit.

 Transactions are aborted in case of non-serializable schedules.

 Cont’d
There are three phases for this concurrency control protocol:

1. Read & Execution 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.
 Cont’d.
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.

Note:
 The techniques are called optimistic because they assume that little
interference will occur and there is no need to do checking during
transaction execution.
Thank you!