Concurrency Control in Database Management system

Concurrency Control
Christalin Nelson | SOCS
1 of 44 16-Apr-24

At a Glance
• Two-Phase Locking Techniques for Concurrency Control
• Concurrency Control Based on Timestamp Ordering
• Validation (Optimistic) Concurrency Control Techniques
• Granularity of Data Items and Multiple Granularity Locking
2 of 44 16-Apr-24

16-Apr-24
Introduction
• Ensure non-interference (isolation property) of concurrently executing
transactions
• The techniques used with Concurrency control protocols (sets of rules) guarantee
serializability of schedules
– Examples
• Locking (two-phase locking protocols)
• Timestamps (Ordering)
• Validation or Certification of transaction (Optimistic protocols)
• Granularity of data item
3 of 44

16-Apr-24
2-Phase Locking Techniques (1/25)
• This technique is based on the concept of “locking data items”
• Lock
– Variable associated with a data item that describes item's status wrt the possible
operations that can be applied to it
– Each data item in DB has one lock mostly
– Used for synchronizing the access of concurrent transactions to the database items
4 of 44

16-Apr-24
• Types of Locks
– Binary Locks
– Shared/Exclusive Locks (or Read/Write Lock)
– Certify Lock
5 of 44

16-Apr-24
• Binary Locks (1/3)
– States/values of Binary Lock
• Unlocked (0): X can be accessed by a DB operation on request
• Locked (1): X cannot be accessed by any DB operation
– Each database item X is associated with a distinct lock. It is denoted as lock(X).
– Binary lock enforces mutual exclusion on the data item
• At most one transaction can hold the lock on a particular item & enters the Critical Section
• Two transactions cannot access the same item concurrently (Interleaving is not allowed)
– Binary locking Operations
• lock_item, unlock_item
• Note: Locking operations are individual units (No Interleaving)
6 of 44

16-Apr-24
– Example (Lock Operations)
• Transaction T requests access to an item X
by issuing a lock_item(X) operation
– If LOCK(X) = 0
» T locks X (i.e. Sets LOCK(X)=1)
» Access X
– If LOCK(X) = 1
» T is forced to wait
• When T is finished using X, it issues an
unlock_item(X) operation i.e. Sets
LOCK(X)=0). Hence, X may be accessed by
other transactions.
Waiting Queue
Not part of lock_item(X)
7 of 44

16-Apr-24
– System Lock Table
• Records/Entries: <Data_item_name, LOCK, Locking_transaction>
• Organized as Hash Table with Hash field = Data_item_name
• Items not in Lock table are considered to be unlocked
– Lock manager subsystem of DBMS
• Keeps track of & controls access to locks
– Uses System Lock table & Waiting Queue
• Rules enforced on Transaction (T)
– (1) T must issue lock_item(X) before any read_item(X) or write_item(X) operations
– (2) T will not issue lock_item(X) if it already holds lock(X)
– (3) T must issue unlock_item(X) after completion of all read_item(X) and write_item(X) ops.
– (4) T will not issue unlock_item(X) unless it already holds lock(X)
8 of 44

16-Apr-24
• Shared/Exclusive Locks (or Read/Write Lock) – 1/5
– Binary lock is too restrictive (at most one transaction can hold a lock on a given item)
– Need for a Multiple-mode lock
• Read on X by different transactions are not conflicting – Suitable for several transactions
• Write on X by different transactions are conflicting – Suitable for at most one transaction
– States/Values of Lock
• Read-locked (Share-lock)
• Write-locked (Exclusive-lock)
• Unlocked
– Locking operations
• read_lock(X), write_lock(X), unlock(X)
• Note: Locking operations are individual units (No Interleaving)
9 of 44

16-Apr-24
Locking and unlocking
operations for two-mode
locks
10 of 44

16-Apr-24
– System Lock Table
• Record/Entries: <Data_item_name, LOCK, No_of_reads, Locking_transaction(s)>
• Items not in Lock table are considered to be unlocked
– Lock manager subsystem of DBMS
• Keeps track of & controls access to locks
– Uses System Lock table & Waiting Queue
• Rules enforced on Transaction (T)
– (1) T must issue read_lock(X) or write_lock(X) before any read_item(X) is performed in T
– (2) T will not issue read_lock(X) if it already holds a read (shared) lock or a write (exclusive) lock on X
– (3) T must issue write_lock(X) before any write_item(X) is performed in T
– (4) T will not issue a write_lock(X) if it already holds a read (shared) lock or write (exclusive) lock on X
– (5) T must issue unlock(X) after all read_item(X) and write_item(X) operations are completed in T
– (6) T will not issue unlock(X) unless it already holds a read (shared) lock or a write (exclusive) lock on X
11 of 44

16-Apr-24
– Lock Conversion
• A transaction that holds a Lock on X is allowed (under certain conditions) to convert the
lock from one locked state to another (upgrade or downgrade)
• E.g.(Upgrade): A transaction T issues read_lock(X). Later T issues write_lock(X) to upgrade.
– If T is the only transaction holding a read_lock(X) while issuing write_lock(X)
» Lock can be upgraded
– Else
» T must wait
• E.g. (Downgrade): T issues write_lock(X). Later T issues read_lock(X) to downgrade.
• Note:
– Lock table includes transaction identifiers in “locking_transaction(s)” field for each lock to store
information on the transactions that hold locks on X
12 of 44

16-Apr-24
– Lock Conversion (contd.)
• read_lock(X) and write_lock(X) operations must be changed appropriately to allow for lock
upgrading and downgrading.
• Note:
– Using binary locks or read/write locks in transactions, does not guarantee
serializability of schedules on its own.
– To guarantee serializability, an additional protocol concerning positioning of locking
and unlocking operations in every transaction should be used
• Example: Two-phase locking (2PL)
13 of 44

16-Apr-24
• Two-Phase Locking (1/3)
– Transaction is divided into two phases
• Expanding/growing (1st) phase: New locks on items can be acquired. None can be released
• Shrinking (2nd) phase: Existing locks can be released but no new locks can be acquired
– Criterion
• A transaction is said to follow 2PL protocol if all locking operations (read_lock, write_lock)
precede its 1st Unlock operation
• A schedule is guaranteed to be serializable if every transaction in the schedule follows 2PL
– If lock conversion is allowed
• Lock Upgrade (read-locked to write-locked) must be done during Expanding phase
• Lock Downgrade (write-locked to read-locked) must be done in Shrinking phase
14 of 44

16-Apr-24
– Transactions T1 and T2 (in pic. below) do not follow 2PL
• In T1: Write_lock(X) follows Unlock(Y)
• In T2: Write_lock(Y) follows Unlock(X)
– Enforce 2PL on T1 and T2 to get T1’ and T2’
15 of 44

16-Apr-24
– 2PL may limit amount of concurrency that can occur in a schedule
• Example
– Transaction T may not be able to release X even after T has completed using X, if T must lock an
additional item Y later; or conversely
» i.e. X must remain locked by T until all items that T needs to read/write have been locked;
only then can X be released by T
– Meanwhile, another transaction seeking to access X may be forced to wait, even though T is
done with X; conversely, if Y is locked earlier than it is needed, another transaction seeking to
access Y is forced to wait even though T is not using Y yet
16 of 44

16-Apr-24
• Variations of Two-Phase Locking (1/3)
– (1) Basic 2PL
– (2) Conservative 2PL (or static 2PL)
• Transaction locks all items it accesses based on its read-set & write-set before it begins
execution
– If any of the predeclared 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 a deadlock-free protocol
• Predeclaring read-set & writeset of a transaction is not possible in many situations
17 of 44

16-Apr-24
– Strict 2PL
• Guarantees strict schedules
• Transaction T does not release any of its exclusive (write) locks until after it commits or
aborts
– Hence, no other transaction can read or write an item that is written by T unless T has
committed, leading to a strict schedule for recoverability
• Strict 2PL is not deadlock-free
18 of 44

16-Apr-24
– Rigorous 2PL
• A more restrictive variation of strict 2PL
• Guarantees strict schedules
• Transaction T does not release any of its locks (exclusive or shared) until after it commits or
aborts, and so it is easier to implement than strict 2PL
• Difference between conservative and rigorous 2PL
– C2PL must lock all its items before it starts, so once transaction starts it is in its shrinking phase
– R2PL does not unlock any of its items until after it terminates (by committing or aborting), so the
transaction is in its expanding phase until it ends
• Note:
– Use of locks can cause two additional problems: deadlock and starvation
19 of 44

16-Apr-24
• Dealing with Deadlock and Starvation
– In a set of two or more transactions, each transaction in the set is in a waiting queue,
waiting for one of the other transactions in the set to release the lock on an item. But
because the other transaction is also waiting, it will never release the lock.
– Example: A partial schedule of T1’ and T2’ that is in deadlock state
20 of 44

16-Apr-24
• Deadlock Prevention Protocols (1/4)
– (1) Conservative 2PL
• Every transaction locks all items it needs in advance. If any item cannot be obtained, none
of the items are locked.
– i.e. Transaction waits and then tries again to lock all items it needs
• Limits concurrency, Not a practical assumption
– (2) Transaction Timestamp based, TS(T)
• Each transaction is assigned a unique timestamp when it starts execution. When a
transaction requests a resource, it includes its timestamp with the request
• If transaction T1 starts before transaction T2, then TS(T1)< TS(T2). T1 is older & T2 is
younger
• Type of algorithms: Wait-Die, Wound-Wait
21 of 44

16-Apr-24
– (2.1) Wait-Die
• Consider: T1 requests a resource that is currently held by T2 and TS(T1) < TS(T2)
– If T1 is the requesting transaction & T2 is holding the resource, T1 (Older) is allowed to wait for
T2 (Younger) to release the resource voluntarily
– If T2 is the requesting transaction & T2 is holding the resource, T2 (Younger) is rolled back and
restarted later ("die")
• The system ensures that older transactions are given priority to wait in the Queue
• If a transaction is rolled back and restarted, it is restarted with a new timestamp
22 of 44

16-Apr-24
– (2.2) Wound-Wait
• Consider: T1 requests a resource that is currently held by T2 and TS(T1) < TS(T2)
– If T1 is the requesting transaction & T2 is holding the resource, T1 (Older) is allowed to wait for
T2 (Younger) to release the resource voluntarily
– If T2 is the requesting transaction & T1 is holding the resource, T1 (Older) is terminated or rolled
back and restarted later ("wounded") & T2 gets the resource.
• The system ensures that younger transactions are given priority.
• If a transaction is terminated or rolled back and restarted, it is restarted with a new
timestamp
23 of 44

16-Apr-24
– (3) No waiting (NW) algorithm
• Each transaction is assigned a priority based on some criteria. Consider, T1 requests a
resource that is currently held by T2 and P(T1) > P (T2)
– If T1 is the requesting transaction & T2 is holding the resource, T1 is allowed to preempt the
resource from T2 immediately, without waiting ("No Waiting"). T2 may be rolled back and
restarted later, potentially with a new priority to reflect their importance or urgency.
– If T2 is the requesting transaction & T1 is holding the resource, T2 is either forced to wait or is
denied access to the resource altogether.
• Ensures that high-priority transactions are not delayed indefinitely by lower-priority
transactions.
– (4) Cautious waiting (CW) algorithm
• It proactively imposes caution on transaction waits. If granting resources could lead to a
cyclic dependency among waiting transactions and eventually in deadlock, it may choose to
roll back the waiting transaction or deny its request for the resource altogether.
24 of 44

16-Apr-24
• Deadlock Detection Protocols
– Suited for short transactions and each transaction uses few items, (or) light
transaction load
– Unsuited for long transactions and each transaction uses many items (or) heavy
transaction load (Deadlock prevention scheme should be preferred)
– Example
• Wait-for Graph (WFG)
A partial schedule of T1’ and T2’ that is in deadlock state WFH for the partial schedule
25 of 44

16-Apr-24
• Wait-for Graph (WFG) – 1/2
– Structure & Process
• Node: Currently executing transaction (say T1 & T2)
• Directed edge (T1 → T2): T1 is waiting to lock an item X that is currently locked by T2
• Drop directed edge (T1 → T2)
– T2 releases the lock(s) on the items that T1 was waiting for
• Cycle depicts deadlock occurrence
– Issue: Determining when to check for a deadlock
– Solutions
• Check for cycle after an edge is added to WFG
• Use criteria like No. of currently executing transactions, and Period of wait (to lock) of
transactions
26 of 44

16-Apr-24
• Wait-for Graph (WFG) – 2/2
– If system is in deadlock state  Abort transaction causing deadlock
– Victim selection algorithm
• Choose transactions to abort
• Algorithm-1
– Do not select transactions that were running for a long time & performed many updates
– Select transactions that have not made many changes (younger transactions)
• Algorithm-2 (Timeouts)
– Abort transaction that waits for period > System-defined timeout period
– Low overhead and simplicity
27 of 44

16-Apr-24
• Starvation
– A transaction cannot proceed for an indefinite period while other transactions
continue normally
• Waiting scheme for locked items is unfair, giving priority to some transactions over others
– Solutions
» (1) Fair waiting scheme (like FCFS queue)  Transactions lock an item in the order in which
they originally requested the lock
» (2) Increase priority of transaction wrt wait time  Eventually gets highest priority &
proceeds
• Victim selection (Algorithm selects same transaction as the victim repeatedly)
– Solutions
» (1) Consider higher priorities for transactions that have been aborted multiple times
» (2) Wait-die & Wound-Wait: Restart aborted transaction with same original timestamp 
Possibility that the same transaction is aborted repeatedly is slim
28 of 44

16-Apr-24
Concurrency Control Based on Timestamp Ordering (1/5)
• Timestamps - TS(T)
– Unique identifier generated/assigned by DBMS to transactions as per submission
order
• (1) Increment a counter each time its value is assigned to a transaction  Periodically reset
counter to zero (when no transactions are executing & a finite max value is reached)
• (2) Use current date/time value of system clock (No two timestamp values are generated
during same clock tick)
29 of 44

16-Apr-24
• Timestamp Ordering (TO) Algorithm
– For each item X accessed by conflicting operations in schedule, the order in which X is
accessed does not violate TO
– DB item X is associated with 2 timestamp (TS) values
• read_TS(X)
– read_TS(X) = TS(T), where T - Youngest transaction that has read X successfully
• write_TS(X)
– write_TS(X) = TS(T), where T - Youngest transaction that has written X successfully
30 of 44

16-Apr-24
• Basic Timestamp Ordering Algorithm
– Check whether conflicting operations violate TO in both cases
• (1) T issues write_item(X)
– (a) If read_TS(X) > TS(T) or write_TS(X) > TS(T)  Reject operation, Abort & roll back T
– (b) Else execute write_item(X) of T, and set write_TS(X) = TS(T)
• (2) T issues read_item(X)
– (a) If write_TS(X) > TS(T)  Reject operation, Abort & roll back T
– (b) If write_TS(X) ≤ TS(T)  Execute read_item(X) of T, and set read_TS(X) = Larger of TS(T) and
current read_TS(X)
– Guarantees conflict serializability using transaction timestamp ordering (TO)
• (2PL) A schedule is serializable by being equivalent to some serial schedule allowed by
locking protocols
• (TO) A schedule is serializable by being equivalent to a particular serial schedule
corresponding to TO  Does not use locks  No deadlocks, Cyclic restart & Starvation may
occur
31 of 44

16-Apr-24
• Strict Timestamp Ordering Algorithm
– If TS(T) > TS(T’) and T(younger) issues read_item(X) or write_item(X)  T waits until T’
that wrote X has committed or aborted
• It is necessary to simulate the locking of X that has been written by transaction T’ until T’ is
either committed or aborted
– Schedules are both strict (for easy recoverability) and (conflict) serializable
32 of 44

16-Apr-24
• Thomas’s Write Rule
– Modification of basic TO algorithm
– Does not enforce conflict serializability. It rejects a few writes by modifying checks for
write_item(X) as follows
• (1) If read_TS(X) > TS(T)  Reject operation, Abort & roll back T
• (2) If write_TS(X) > TS(T)  Reject operation, Continue processing
– T’(Younger as per TO) has already written X. Hence, ignore write_item(X) of T (Older) as it is
already outdated and obsolete
– Note: Any conflict would be met in (1)
• (3) Else  Execute write_item(X) of T, set write_TS(X) = TS(T)
33 of 44

16-Apr-24
Validation (Optimistic) Concurrency Control Techniques (1/2)
• Checks performed before execution of DB operation could be an overhead
– (2PL) Check to determine whether X being accessed is locked
– (In TO) Transaction timestamp is checked against read & write timestamps of X
• Features
– No check is done during transaction execution (Assumption: Interference is rare)
– Uses transaction timestamps
– System should keep
• Write_sets & read_sets of the transactions
• Keep start and end times of each transaction for some of the phases
34 of 44

16-Apr-24
Validation (Optimistic) Concurrency Control Techniques (2/2)
• Algorithm includes 3 phases
– (1) Read phase
• Transaction can read committed X from DB
• Updates applied on local copy of X in transaction's workspace
– (2) Validation phase
• Ensure that serializability is not violated
• In Ti’s Validation phase, check if one condition is true for each Tj that has committed or in validation phase
– (1) Ti starts its Read phase after Tj completes its Write phase
– (2) Ti starts its Write phase after Tj completes its Write phase, Intersection of read_set of Ti & write_set of Tj is null
– (3) Ti completes its Read phase after Tj completes its Read phase, both read_set and write_set of Ti have no items in
common with write_set of Tj
• If any one of these 3 conditions is true  No interference, Ti is validated successfully
• If none of these three conditions holds  Validation of Ti fails, Abort & restart Ti later
– (3) Write phase
• If validation phase is successful  Apply transaction updates to DB
• Else  Discard updates, Restart transaction
35 of 44

16-Apr-24
Granularity of Data Items (1/2)
• Granularity (Size of data items) of DB item
– A DB record
– A field value of a DB record
– A disk block
– A whole file
– Whole database
• Granularity affects performance of concurrency control and recovery
Fine granularity
Course granularity
36 of 44

16-Apr-24
Granularity of Data Items (2/2)
• Granularity Level Considerations for Locking
– Larger granularity  Lower degree of concurrency
• Granularity is a disk block (X)
– If T1 needs R1 which is stored in X, it should lock X (whole block)  If T2 wants R2 which is also
stored in X, R2 is forced to wait due to conflicting lock mode
• Granularity is a single record
– T2 would be able to proceed
– Smaller granularity  More DB items
• Lock manager needs to handle more no. of active locks
• Higher overhead (more lock & unlock operations)
• More storage space for lock table or storing timestamps for each X
– Best item size depends on Type of transactions
• If less number of records are accessed  Granularity can be a record
• If more number of records are accessed  Granularity can be a block or file
DB system should
support multiple
levels of granularity
37 of 44

16-Apr-24
Multiple Granularity Locking (1/6)
• Simple granularity hierarchy
– Used to illustrate Multiple Granularity Locking (MGL), where a lock (additional types of
locks) can be requested at any level
38 of 44

16-Apr-24
• Consider using only shared and exclusive lock types
– Case-1
• T1 wants to update all records in f1  T1 requests file-level exclusive lock on f1  Granted
 All f1’s pages & records are locked in exclusive mode  T2 wants to read record r111
from page p11 of file f1  T2 requests record-level shared lock on r111  Lock manager
performs Tree traversal (from leaf r111 towards db) to verify lock compatibility  Conflicting
lock is held on item  Deny lock request for r111  T2 is blocked and waits
– Traversal is fairly efficient
– Case-2
• T2 wants to read record r111 from page p11 of file f1  T2 requests record-level shared lock
on r111  Granted  T1 wants to update all records in f1  T1 requests file-level exclusive
lock on f1  Lock manager performs Tree traversal to check all nodes that are descendants
of node f1 to verify lock compatibility ….
– Traversal is difficult (Solution: Intention Locks)
39 of 44

16-Apr-24
• Intention locks
– Transaction indicates its required lock type (shared or
exclusive) from one of node’s descendants along the path
from the root to the desired node.
– Types
• (1) Intention-shared (IS)
– One or more Shared lock(s) will be requested on some
descendant node(s)
• (2) Intention-exclusive (IX)
– One or more Exclusive lock(s) will be requested on some
descendant node(s)
• (3) Shared-intention-exclusive (SIX)
– Current node is locked in shared mode, but one or more
exclusive lock(s) will be requested on some descendant node(s)
Lock compatibility matrix
40 of 44

16-Apr-24
• Rules of MGL protocol
– (1) Conflicting locks cannot be granted. i.e. Adhere to Lock compatibility
– (2) Lock the Root of the tree first, in any mode
– (3) T can lock node N in S or IS mode only if T locks the parent of N in IS or IX mode
– (4) T can lock node N in X, IX, or SIX mode only if T locks parent of N in IX or SIX mode
– (5) T can lock a node N only if T has not unlocked any node
– (6) T can unlock a node N only if T has currently not locked any of the children of N
• Note:
– Rules 2, 3, and 4: State conditions when a transaction may lock a given node in any
lock modes
– Rules 5 and 6: Enforce 2PL rules to produce serializable schedules
41 of 44

16-Apr-24
Possible serializable schedule
Transactions
(1) T1 wants to update records r111 and r211
(2) T2 wants to update all records on page p12
(3) T3 wants to read record r11j and entire f2 file
Granularity Hierarchy
Locking Operation
<lock_type>(<item>)
42 of 44

16-Apr-24
• MGL protocol is suited when processing a mix of transactions including
– (1) Short transactions that access only a few items (records or fields)
– (2) Long transactions that access entire files
– Note: MGL vs. Single-level granularity locking approach
• Less transaction blocking
• Less locking overhead is incurred
43 of 44

Thank You
16-Apr-24
16-Apr-24
44 of 44

Concurrency Control in Database Management system

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Concurrency Control in Database Management system

Similar to Concurrency Control in Database Management system (20)

More from Christalin Nelson

More from Christalin Nelson (13)

Recently uploaded

Recently uploaded (20)

Concurrency Control in Database Management system