Chapter 18 (TCDS)

Concurrency
Control
Sukarna Barua
Associate Professor, CSE, BUET
03/20/2024
 Shared and Exclusive locks
 Instead of a single lock, two different locks are used by the scheduler.

 Shared lock: If wants to read , but not write, it requests shared lock.
- action of shared lock on

 Exclusive lock: If wants to write , it must obtain an exclusive lock.

- : action of exclusive lock on

 An exclusive lock is stronger than a shared lock.

 Generally for write operation, but not intended for read operation

03/20/2024
Concurrency Requirement Under Shared and
Exclusive Locks
 Consistency of transaction:
- A read action must be preceded by or with no intervening

-A write action must be preceded by with no intervening .

-All locks must be followed by unlock of the same element.

 Two-phase locking of transactions:

- All locking must precede all unlocking.

03/20/2024
 Concurrency Requirement Under
Shared and Exclusive Locks
 Legality of schedules:
-An element must be locked exclusively by one transaction.
-An element may locked in shared mode by several transactions.
-If appears in a schedule, then there cannot be a following or
for some other than , without an intervening .
-If appears in a schedule, there cannot be a following for
without an intervening .

03/20/2024
 Concurrency Requirement Under
Shared and Exclusive Locks
 Consider the below schedule with shared and exclusive locks.
 Note that the schedule is conflict-serializable

03/20/2024
 Upgrading locks
 Locks can be upgraded by a transaction.
 Upgrading works from a shared lock to an
exclusive lock.
 Upgrading only granted when other transactions
releases locks.
 Upgrading allows more concurrency.
 Example: Consider the following schedule.
 obtains a shared lock on B. Later, it requests
an exclusive lock on B.
 If obtained an exclusive lock initially,
would have denied and could not perform
computations on B.
03/20/2024
 Potential Deadlock Due to Lock
Upgrade
 Indiscriminate use of upgrade can lead to deadlock situation.
 Consider the following schedule which is in deadlock.
 and both have shared lock on A. They perform computations on A.
 Then both and requests upgrade of lock on A. Both of them waits for the other to
release lock.

03/20/2024
 Update Lock: Deadlock Prevention
 A third mode of lock is “update” lock.
 A transaction obtains “update” lock on A if it wants to upgrade it later.
 An update lock is basically a shared lock except that:
- It can be upgraded to exclusive lock later.
- A shared lock cannot be upgraded to an exclusive lock.
- This prevents deadlock due to upgrading of locks.

03/20/2024
 Update Lock: Compatibility Matrix
 Lock compatibility matrix shows which type of locks can be granted on given the
current locked status of

 Note that
- No lock can be granted on to a transaction, if another transaction is holding
an update/exclusive/shared lock on .
-An shared/update lock can be given to a transaction, despite another transaction
holding a shared lock on .
03/20/2024
 Structure of lock table
 DBMS schedule maintains a lock table.
 A lock tables associates locking information with each element X.
 A lock table may be implemented as a hash table, using db elements as hash key.
 Any element without a lock does not appear in lock table.

03/20/2024
 Structure of lock table
 A lock table may include following information:
 Group mode: A summary of the most stringent
lock held on X.
 A new lock request on X is compared with this
group mode instead of every locks held on X
by other transactions.
 Group mode can be S/X/U
- S: Only shared locks are held.
- U: One update lock and zero or more shared locks.
- X: One exclusive lock only.
 Waiting bit: "Yes" means at least one transaction is waiting for a lock.
 A list: Description of all transactions holding locks on A or waiting for a lock on A.

03/20/2024
 Handling Lock Requests
 Transaction T requests a lock on A:
 If there is no lock-table entry for A, then entry is created and request is granted.
 If there is a lock table entry for A, find the group mode:
- If it is U/X, then no lock can be granted. T is denied, and put on wait list in the
lock table entry.
- If it is S, then a shared or update lock can be granted. Group mode is updated
accordingly as per granted lock (S/U).

03/20/2024
 Handling Unlock Requests
 Transaction T requests an unlock on A:
 T's entry is deleted from the list.
 If lock held by T group mode:
 No need to change group mode. [Why?]
 If lock held by T group mode, examine the list to find new group mode:
 If T's lock was S/U, there could be:
- Others holding S: Group mode becomes S.
- No one holding: New group mode depends on wait list.
 If T's lock was X:
- Then no other holding a lock.
- New group mode depends on waiting list.

03/20/2024
 Handling Unlock Requests
 Transaction T requests an unlock on A:

 Wait is contacted when “wait=yes”

 Appropriate lock is granted to a transaction in wait list.
 FCFS or Priority to shared locks may be used to choose wait list transactions
for granting a loc

03/20/2024
Timestamp based concurrency Control
 Transaction Timestamp:
 Scheduler assigns a unique number, timestamp to each transaction.
 Timestamp issued in ascending order.
 Timestamp may be implemented -
 Using system clock
 Using a counter maintained by scheduler.
 Scheduler maintains a table for active transactions and their timestamps.
 A type of “optimistic” concurrency control protocol
 Assumes transactions conflicts are rare

03/20/2024
Timestamp based concurrency Control
 Timestamp for DB element X:
 In timestamp based concurrency control, each database element has two
timestamps and an additional bit:
 the read time of , highest timestamp of a transaction that has read .

 The write timestamp of , highest timestamp of a transaction that has written .

 C(X): the commit bit for , which is true if and only if the most recent transaction to write has
committed or not.

03/20/2024
Timestamp based concurrency Control
 Presumed serial order:
 In timestamp concurrency control, schedule must be equiv. to a presumed serial
order.
 The serial order is defined by timestamps.
 If , then serial order of schedule will be
 The serial order is maintained in the schedule.
 and are prohibited if serial order is violated. [ corresponding transactions are aborted and
restarted! ]

 is younger than
 is older than .
03/20/2024
 Practically Unrealizable Behavior
 Case 1 - Read too late: Transaction tries to read , but
- Let be the transaction written to .
- started after and has written .
- now will read which is updated by a transaction that started after .
- This is practically unrealizable. [conflict violating serial order]
- should be aborted and restarted. [why? to maintain serial order!]

03/20/2024
 Practically Unrealizable Behavior
 Case 2 - Write too late: Transaction tries to write but
- A transaction starts after but read before writes to .
- Now cannot continue to write as it is unrealizable.
[conflict violating serial order]
- is aborted. [why? to maintain serial order!]

03/20/2024
 Problems With Dirty Read
 Case 3 - Dirty Read:
 reads and was written by .
 . [T is younger]
 Read of is physically realizable [don’t conflict violates serial order].
 This is called dirty read. [read is dirty when U is not committed]
 What happens if abort later?
 's read become uncommitted dirty read.
 Should not be allowed!

03/20/2024
 Problems With Dirty Read
 How to avoid dirty read?:
 Check commit bit .
 If true, then read is granted;
 Otherwise, can be put to wait to avoid dirty uncommitted read.

03/20/2024
 Problems With Thomas Write Rule
 Case 4 - Thomas write rule and associated problem: wants to write .
 T is older, thus aborted.
 and
 Serializable due to write without read. [ Serial order: (T, U) ]
 ’s write can be skipped. [ why? ].
 This is known as Thomas write rule. [ allows more concurrency, do not preserve conflict-
serializability, but preserver serializability! ]

03/20/2024
 Problems With Thomas Write Rule
 Case 4 - Thomas write rule and associated problem:
- Say later aborts but is committed already.
- 's value should be reverted from .
- Since is committed, it's value should be in .
- But write of is skipped already! [ should not have happened ]

03/20/2024
Rules for Timestamp Based Scheduling
 Timestamp concurrency rules
• Rule for granting read
(a) If The read is physically realizable.
- If is true, grant the request. If set
otherwise don’t change .
- If is false, delay until becomes true or transaction that
wrote aborts.

(b) If The read is physically unrealizable.

- Rollback ; abort and restart with a new timestamp.

03/20/2024
Rules for Timestamp Based Scheduling
 Timestamp concurrency rules
• Rule for granting write action
(a) If and The write is physically realizable.
- Write the new value of . Set , and .
(b) If , but : The write is physically realizable,
but a later value is already written to .
- If is , then ignore write of .
- If is , delay until becomes true or the transaction that
wrote aborts.
(c) If The write is physically unrealizable.
- Abort and restartwith a new timestamp.
03/20/2024
Rules for Timestamp Based Scheduling
 Timestamp concurrency rules
• Rules for granting commit :
- Set for all database elements written by .
- If any transactions are waiting, these are allowed to proceed.

• Rules for granting abort T:

- Any transactions waiting on element that wrote must repeat its attempt to
read/write

03/20/2024
Rules for Timestamp Based Scheduling
 Analyze the schedule shown below for timestamp based scheduling.
 is aborted. Why?
 does not update . Why?

03/20/2024
 Multiversion Concurrency Control
(MVCC)
 A variation of timestamp-based concurrency control.
 Assume a transaction issues and
 T is aborted as X is updated in future.
 is aborted in below example [TS(

03/20/2024
 Timestamps vs Locking
 Timestamp is superior when most transactions are read-only.
 In high conflict situations, locking performs better.
 Locking will frequently delay transactions as they wait for locks

 If concurrent transactions frequently read/write, then rollbacks will be frequent in a

timestamp scheduler leading to more delays.
 Locking prevents such rollbacks as it maintains conflict-serializability.

03/20/2024