SlideShare a Scribd company logo
1 of 44
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
4 of 44
16-Apr-24
2-Phase Locking Techniques (2/25)
• Types of Locks
– Binary Locks
– Shared/Exclusive Locks (or Read/Write Lock)
– Certify Lock
Christalin Nelson | SOCS
5 of 44
16-Apr-24
2-Phase Locking Techniques (3/25)
• 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)
Christalin Nelson | SOCS
6 of 44
16-Apr-24
2-Phase Locking Techniques (4/25)
• Binary Locks (2/3)
– 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.
Christalin Nelson | SOCS
Waiting Queue
Not part of lock_item(X)
7 of 44
16-Apr-24
2-Phase Locking Techniques (5/25)
• Binary Locks (3/3)
– 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)
Christalin Nelson | SOCS
8 of 44
16-Apr-24
2-Phase Locking Techniques (6/25)
• 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)
Christalin Nelson | SOCS
9 of 44
16-Apr-24
Christalin Nelson | SOCS
Locking and unlocking
operations for two-mode
locks
10 of 44
16-Apr-24
2-Phase Locking Techniques (8/25)
• Shared/Exclusive Locks (or Read/Write Lock) – 3/5
– 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
Christalin Nelson | SOCS
11 of 44
16-Apr-24
2-Phase Locking Techniques (9/25)
• Shared/Exclusive Locks (or Read/Write Lock) – 4/5
– 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
Christalin Nelson | SOCS
12 of 44
16-Apr-24
2-Phase Locking Techniques (10/25)
• Shared/Exclusive Locks (or Read/Write Lock) – 5/5
– 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)
Christalin Nelson | SOCS
13 of 44
16-Apr-24
2-Phase Locking Techniques (11/25)
• 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
Christalin Nelson | SOCS
14 of 44
16-Apr-24
2-Phase Locking Techniques (12/25)
• Two-Phase Locking (2/3)
– 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’
Christalin Nelson | SOCS
15 of 44
16-Apr-24
2-Phase Locking Techniques (13/25)
• Two-Phase Locking (3/3)
– 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
Christalin Nelson | SOCS
16 of 44
16-Apr-24
2-Phase Locking Techniques (14/25)
• 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
Christalin Nelson | SOCS
17 of 44
16-Apr-24
2-Phase Locking Techniques (15/25)
• Variations of Two-Phase Locking (2/3)
– 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
Christalin Nelson | SOCS
18 of 44
16-Apr-24
2-Phase Locking Techniques (16/25)
• Variations of Two-Phase Locking (3/3)
– 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
Christalin Nelson | SOCS
19 of 44
16-Apr-24
2-Phase Locking Techniques (17/25)
• 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
Christalin Nelson | SOCS
20 of 44
16-Apr-24
2-Phase Locking Techniques (18/25)
• 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
Christalin Nelson | SOCS
21 of 44
16-Apr-24
2-Phase Locking Techniques (19/25)
• Deadlock Prevention Protocols (2/4)
– (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
Christalin Nelson | SOCS
22 of 44
16-Apr-24
2-Phase Locking Techniques (20/25)
• Deadlock Prevention Protocols (3/4)
– (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
Christalin Nelson | SOCS
23 of 44
16-Apr-24
2-Phase Locking Techniques (21/25)
• Deadlock Prevention Protocols (4/4)
– (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.
Christalin Nelson | SOCS
24 of 44
16-Apr-24
2-Phase Locking Techniques (22/25)
• 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)
Christalin Nelson | SOCS
A partial schedule of T1’ and T2’ that is in deadlock state WFH for the partial schedule
25 of 44
16-Apr-24
2-Phase Locking Techniques (23/25)
• 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
Christalin Nelson | SOCS
26 of 44
16-Apr-24
2-Phase Locking Techniques (24/25)
• 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
Christalin Nelson | SOCS
27 of 44
16-Apr-24
2-Phase Locking Techniques (25/25)
• 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
Christalin Nelson | SOCS
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)
Christalin Nelson | SOCS
29 of 44
16-Apr-24
Concurrency Control Based on Timestamp Ordering (2/5)
• 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
Christalin Nelson | SOCS
30 of 44
16-Apr-24
Concurrency Control Based on Timestamp Ordering (3/5)
• 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
Christalin Nelson | SOCS
31 of 44
16-Apr-24
Concurrency Control Based on Timestamp Ordering (4/5)
• 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
Christalin Nelson | SOCS
32 of 44
16-Apr-24
Concurrency Control Based on Timestamp Ordering (5/5)
• 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)
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
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
Christalin Nelson | SOCS
38 of 44
16-Apr-24
Multiple Granularity Locking (2/6)
• 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)
Christalin Nelson | SOCS
39 of 44
16-Apr-24
Multiple Granularity Locking (3/6)
• 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)
Christalin Nelson | SOCS
Lock compatibility matrix
40 of 44
16-Apr-24
Multiple Granularity Locking (4/6)
• 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
Christalin Nelson | SOCS
41 of 44
16-Apr-24
Christalin Nelson | SOCS
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
Multiple Granularity Locking (6/6)
• 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
Christalin Nelson | SOCS
43 of 44
Thank You
Christalin Nelson | SOCS
16-Apr-24
16-Apr-24
44 of 44

More Related Content

What's hot

Data Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdfData Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdfChristalin Nelson
 
Step by Step Restore rman to different host
Step by Step Restore rman to different hostStep by Step Restore rman to different host
Step by Step Restore rman to different hostOsama Mustafa
 
Oracle Exadata Cloud Services guide from practical experience - OOW19
Oracle Exadata Cloud Services guide from practical experience - OOW19Oracle Exadata Cloud Services guide from practical experience - OOW19
Oracle Exadata Cloud Services guide from practical experience - OOW19Nelson Calero
 
Oracle Data Redaction
Oracle Data RedactionOracle Data Redaction
Oracle Data RedactionIvica Arsov
 
Exadata
ExadataExadata
Exadatatalek
 
RocksDB compaction
RocksDB compactionRocksDB compaction
RocksDB compactionMIJIN AN
 
PostgreSQL Administration for System Administrators
PostgreSQL Administration for System AdministratorsPostgreSQL Administration for System Administrators
PostgreSQL Administration for System AdministratorsCommand Prompt., Inc
 
Microsoft SQL Server - Files and Filegroups
Microsoft SQL Server - Files and FilegroupsMicrosoft SQL Server - Files and Filegroups
Microsoft SQL Server - Files and FilegroupsNaji El Kotob
 
Rman Presentation
Rman PresentationRman Presentation
Rman PresentationRick van Ek
 
Database performance tuning and query optimization
Database performance tuning and query optimizationDatabase performance tuning and query optimization
Database performance tuning and query optimizationDhani Ahmad
 
MySQL Advanced Administrator 2021 - 네오클로바
MySQL Advanced Administrator 2021 - 네오클로바MySQL Advanced Administrator 2021 - 네오클로바
MySQL Advanced Administrator 2021 - 네오클로바NeoClova
 

What's hot (20)

Data Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdfData Modeling - Enhanced ER diagrams & Mapping.pdf
Data Modeling - Enhanced ER diagrams & Mapping.pdf
 
Database overview
Database overviewDatabase overview
Database overview
 
Storage system architecture
Storage system architectureStorage system architecture
Storage system architecture
 
Sql commands
Sql commandsSql commands
Sql commands
 
Step by Step Restore rman to different host
Step by Step Restore rman to different hostStep by Step Restore rman to different host
Step by Step Restore rman to different host
 
Process Synchronization
Process SynchronizationProcess Synchronization
Process Synchronization
 
Oracle Exadata Cloud Services guide from practical experience - OOW19
Oracle Exadata Cloud Services guide from practical experience - OOW19Oracle Exadata Cloud Services guide from practical experience - OOW19
Oracle Exadata Cloud Services guide from practical experience - OOW19
 
Oracle DBA
Oracle DBAOracle DBA
Oracle DBA
 
Oracle Data Redaction
Oracle Data RedactionOracle Data Redaction
Oracle Data Redaction
 
Exadata
ExadataExadata
Exadata
 
RocksDB compaction
RocksDB compactionRocksDB compaction
RocksDB compaction
 
DB2 utilities
DB2 utilitiesDB2 utilities
DB2 utilities
 
PostgreSQL Administration for System Administrators
PostgreSQL Administration for System AdministratorsPostgreSQL Administration for System Administrators
PostgreSQL Administration for System Administrators
 
Database concepts
Database conceptsDatabase concepts
Database concepts
 
Microsoft SQL Server - Files and Filegroups
Microsoft SQL Server - Files and FilegroupsMicrosoft SQL Server - Files and Filegroups
Microsoft SQL Server - Files and Filegroups
 
Rman Presentation
Rman PresentationRman Presentation
Rman Presentation
 
RDBMS vs NoSQL
RDBMS vs NoSQLRDBMS vs NoSQL
RDBMS vs NoSQL
 
MS-SQL SERVER ARCHITECTURE
MS-SQL SERVER ARCHITECTUREMS-SQL SERVER ARCHITECTURE
MS-SQL SERVER ARCHITECTURE
 
Database performance tuning and query optimization
Database performance tuning and query optimizationDatabase performance tuning and query optimization
Database performance tuning and query optimization
 
MySQL Advanced Administrator 2021 - 네오클로바
MySQL Advanced Administrator 2021 - 네오클로바MySQL Advanced Administrator 2021 - 네오클로바
MySQL Advanced Administrator 2021 - 네오클로바
 

Similar to Concurrency Control in Database Management system

Chapter Three _Concurrency Control Techniques_ETU.ppt
Chapter Three _Concurrency Control Techniques_ETU.pptChapter Three _Concurrency Control Techniques_ETU.ppt
Chapter Three _Concurrency Control Techniques_ETU.ppthaymanot taddesse
 
Concurrency Control in Database Management System
Concurrency Control in Database Management SystemConcurrency Control in Database Management System
Concurrency Control in Database Management SystemJanki Shah
 
Concurrency control
Concurrency controlConcurrency control
Concurrency controlJaya Jeswani
 
Unit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyUnit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyPritishMajumdar3
 
Unit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyUnit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyPritishMajumdar3
 
DBMS Presentation.pptx
DBMS Presentation.pptxDBMS Presentation.pptx
DBMS Presentation.pptxPravinBhargav1
 
DBMS (Deadlock, deadlock prevention, 2phase locking)
DBMS (Deadlock, deadlock prevention, 2phase locking)DBMS (Deadlock, deadlock prevention, 2phase locking)
DBMS (Deadlock, deadlock prevention, 2phase locking)Gaurav Solanki
 
concurrencycontrol from power pint pdf a
concurrencycontrol  from power pint pdf aconcurrencycontrol  from power pint pdf a
concurrencycontrol from power pint pdf aMdAyanParwez
 
Concurrency Management
Concurrency ManagementConcurrency Management
Concurrency ManagementSURBHI SAROHA
 
Concurrency Control & Deadlock Handling
Concurrency Control & Deadlock HandlingConcurrency Control & Deadlock Handling
Concurrency Control & Deadlock HandlingMeghaj Mallick
 
5-Chapter Five - Concurrenc.ppt
5-Chapter Five - Concurrenc.ppt5-Chapter Five - Concurrenc.ppt
5-Chapter Five - Concurrenc.pptDadiTesfaye
 

Similar to Concurrency Control in Database Management system (20)

Chapter Three _Concurrency Control Techniques_ETU.ppt
Chapter Three _Concurrency Control Techniques_ETU.pptChapter Three _Concurrency Control Techniques_ETU.ppt
Chapter Three _Concurrency Control Techniques_ETU.ppt
 
Concurrency Control in Database Management System
Concurrency Control in Database Management SystemConcurrency Control in Database Management System
Concurrency Control in Database Management System
 
Concurrency control
Concurrency controlConcurrency control
Concurrency control
 
Unit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyUnit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovely
 
Unit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovelyUnit 4 Concurrency control.pptx dbms lovely
Unit 4 Concurrency control.pptx dbms lovely
 
UNIT II.pptx
UNIT II.pptxUNIT II.pptx
UNIT II.pptx
 
2 con control
2 con control2 con control
2 con control
 
DBMS Presentation.pptx
DBMS Presentation.pptxDBMS Presentation.pptx
DBMS Presentation.pptx
 
DBMS (Deadlock, deadlock prevention, 2phase locking)
DBMS (Deadlock, deadlock prevention, 2phase locking)DBMS (Deadlock, deadlock prevention, 2phase locking)
DBMS (Deadlock, deadlock prevention, 2phase locking)
 
concurrencycontrol from power pint pdf a
concurrencycontrol  from power pint pdf aconcurrencycontrol  from power pint pdf a
concurrencycontrol from power pint pdf a
 
Concurrency control
Concurrency controlConcurrency control
Concurrency control
 
Concurrency Management
Concurrency ManagementConcurrency Management
Concurrency Management
 
Concurrency Control & Deadlock Handling
Concurrency Control & Deadlock HandlingConcurrency Control & Deadlock Handling
Concurrency Control & Deadlock Handling
 
Chapter18
Chapter18Chapter18
Chapter18
 
Concurrency control
Concurrency control Concurrency control
Concurrency control
 
Concurrency Control
Concurrency ControlConcurrency Control
Concurrency Control
 
concurrency control
concurrency controlconcurrency control
concurrency control
 
Unit 5 dbms
Unit 5 dbmsUnit 5 dbms
Unit 5 dbms
 
5-Chapter Five - Concurrenc.ppt
5-Chapter Five - Concurrenc.ppt5-Chapter Five - Concurrenc.ppt
5-Chapter Five - Concurrenc.ppt
 
concurrency-control
concurrency-controlconcurrency-control
concurrency-control
 

More from Christalin Nelson (17)

Packages and Subpackages in Java
Packages and Subpackages in JavaPackages and Subpackages in Java
Packages and Subpackages in Java
 
Bitwise complement operator
Bitwise complement operatorBitwise complement operator
Bitwise complement operator
 
Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2Advanced Data Structures - Vol.2
Advanced Data Structures - Vol.2
 
Deadlocks
DeadlocksDeadlocks
Deadlocks
 
CPU Scheduling
CPU SchedulingCPU Scheduling
CPU Scheduling
 
Process Management
Process ManagementProcess Management
Process Management
 
Applications of Stack
Applications of StackApplications of Stack
Applications of Stack
 
Data Storage and Information Management
Data Storage and Information ManagementData Storage and Information Management
Data Storage and Information Management
 
Application Middleware Overview
Application Middleware OverviewApplication Middleware Overview
Application Middleware Overview
 
Network security
Network securityNetwork security
Network security
 
Directory services
Directory servicesDirectory services
Directory services
 
System overview
System overviewSystem overview
System overview
 
Storage overview
Storage overviewStorage overview
Storage overview
 
Computer Fundamentals-2
Computer Fundamentals-2Computer Fundamentals-2
Computer Fundamentals-2
 
Computer Fundamentals - 1
Computer Fundamentals - 1Computer Fundamentals - 1
Computer Fundamentals - 1
 
Advanced data structures vol. 1
Advanced data structures   vol. 1Advanced data structures   vol. 1
Advanced data structures vol. 1
 
Programming in c++
Programming in c++Programming in c++
Programming in c++
 

Recently uploaded

Major project report on Tata Motors and its marketing strategies
Major project report on Tata Motors and its marketing strategiesMajor project report on Tata Motors and its marketing strategies
Major project report on Tata Motors and its marketing strategiesAmanpreetKaur157993
 
PSYPACT- Practicing Over State Lines May 2024.pptx
PSYPACT- Practicing Over State Lines May 2024.pptxPSYPACT- Practicing Over State Lines May 2024.pptx
PSYPACT- Practicing Over State Lines May 2024.pptxMarlene Maheu
 
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptxAnalyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptxLimon Prince
 
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...Denish Jangid
 
Spring gala 2024 photo slideshow - Celebrating School-Community Partnerships
Spring gala 2024 photo slideshow - Celebrating School-Community PartnershipsSpring gala 2024 photo slideshow - Celebrating School-Community Partnerships
Spring gala 2024 photo slideshow - Celebrating School-Community Partnershipsexpandedwebsite
 
e-Sealing at EADTU by Kamakshi Rajagopal
e-Sealing at EADTU by Kamakshi Rajagopale-Sealing at EADTU by Kamakshi Rajagopal
e-Sealing at EADTU by Kamakshi RajagopalEADTU
 
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading RoomSternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading RoomSean M. Fox
 
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文中 央社
 
philosophy and it's principles based on the life
philosophy and it's principles based on the lifephilosophy and it's principles based on the life
philosophy and it's principles based on the lifeNitinDeodare
 
Đề tieng anh thpt 2024 danh cho cac ban hoc sinh
Đề tieng anh thpt 2024 danh cho cac ban hoc sinhĐề tieng anh thpt 2024 danh cho cac ban hoc sinh
Đề tieng anh thpt 2024 danh cho cac ban hoc sinhleson0603
 
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽中 央社
 
Graduate Outcomes Presentation Slides - English (v3).pptx
Graduate Outcomes Presentation Slides - English (v3).pptxGraduate Outcomes Presentation Slides - English (v3).pptx
Graduate Outcomes Presentation Slides - English (v3).pptxneillewis46
 
Improved Approval Flow in Odoo 17 Studio App
Improved Approval Flow in Odoo 17 Studio AppImproved Approval Flow in Odoo 17 Studio App
Improved Approval Flow in Odoo 17 Studio AppCeline George
 
demyelinated disorder: multiple sclerosis.pptx
demyelinated disorder: multiple sclerosis.pptxdemyelinated disorder: multiple sclerosis.pptx
demyelinated disorder: multiple sclerosis.pptxMohamed Rizk Khodair
 
male presentation...pdf.................
male presentation...pdf.................male presentation...pdf.................
male presentation...pdf.................MirzaAbrarBaig5
 
diagnosting testing bsc 2nd sem.pptx....
diagnosting testing bsc 2nd sem.pptx....diagnosting testing bsc 2nd sem.pptx....
diagnosting testing bsc 2nd sem.pptx....Ritu480198
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...Nguyen Thanh Tu Collection
 
8 Tips for Effective Working Capital Management
8 Tips for Effective Working Capital Management8 Tips for Effective Working Capital Management
8 Tips for Effective Working Capital ManagementMBA Assignment Experts
 

Recently uploaded (20)

Major project report on Tata Motors and its marketing strategies
Major project report on Tata Motors and its marketing strategiesMajor project report on Tata Motors and its marketing strategies
Major project report on Tata Motors and its marketing strategies
 
PSYPACT- Practicing Over State Lines May 2024.pptx
PSYPACT- Practicing Over State Lines May 2024.pptxPSYPACT- Practicing Over State Lines May 2024.pptx
PSYPACT- Practicing Over State Lines May 2024.pptx
 
“O BEIJO” EM ARTE .
“O BEIJO” EM ARTE                       .“O BEIJO” EM ARTE                       .
“O BEIJO” EM ARTE .
 
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptxAnalyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
Analyzing and resolving a communication crisis in Dhaka textiles LTD.pptx
 
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...
Basic Civil Engineering notes on Transportation Engineering, Modes of Transpo...
 
Spring gala 2024 photo slideshow - Celebrating School-Community Partnerships
Spring gala 2024 photo slideshow - Celebrating School-Community PartnershipsSpring gala 2024 photo slideshow - Celebrating School-Community Partnerships
Spring gala 2024 photo slideshow - Celebrating School-Community Partnerships
 
e-Sealing at EADTU by Kamakshi Rajagopal
e-Sealing at EADTU by Kamakshi Rajagopale-Sealing at EADTU by Kamakshi Rajagopal
e-Sealing at EADTU by Kamakshi Rajagopal
 
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading RoomSternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
Sternal Fractures & Dislocations - EMGuidewire Radiology Reading Room
 
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文
會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文會考英文
 
philosophy and it's principles based on the life
philosophy and it's principles based on the lifephilosophy and it's principles based on the life
philosophy and it's principles based on the life
 
Đề tieng anh thpt 2024 danh cho cac ban hoc sinh
Đề tieng anh thpt 2024 danh cho cac ban hoc sinhĐề tieng anh thpt 2024 danh cho cac ban hoc sinh
Đề tieng anh thpt 2024 danh cho cac ban hoc sinh
 
Mattingly "AI & Prompt Design: Named Entity Recognition"
Mattingly "AI & Prompt Design: Named Entity Recognition"Mattingly "AI & Prompt Design: Named Entity Recognition"
Mattingly "AI & Prompt Design: Named Entity Recognition"
 
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽
會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽會考英聽
 
Graduate Outcomes Presentation Slides - English (v3).pptx
Graduate Outcomes Presentation Slides - English (v3).pptxGraduate Outcomes Presentation Slides - English (v3).pptx
Graduate Outcomes Presentation Slides - English (v3).pptx
 
Improved Approval Flow in Odoo 17 Studio App
Improved Approval Flow in Odoo 17 Studio AppImproved Approval Flow in Odoo 17 Studio App
Improved Approval Flow in Odoo 17 Studio App
 
demyelinated disorder: multiple sclerosis.pptx
demyelinated disorder: multiple sclerosis.pptxdemyelinated disorder: multiple sclerosis.pptx
demyelinated disorder: multiple sclerosis.pptx
 
male presentation...pdf.................
male presentation...pdf.................male presentation...pdf.................
male presentation...pdf.................
 
diagnosting testing bsc 2nd sem.pptx....
diagnosting testing bsc 2nd sem.pptx....diagnosting testing bsc 2nd sem.pptx....
diagnosting testing bsc 2nd sem.pptx....
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
 
8 Tips for Effective Working Capital Management
8 Tips for Effective Working Capital Management8 Tips for Effective Working Capital Management
8 Tips for Effective Working Capital Management
 

Concurrency Control in Database Management system

  • 1. Concurrency Control Christalin Nelson | SOCS 1 of 44 16-Apr-24
  • 2. 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 Christalin Nelson | SOCS 2 of 44 16-Apr-24
  • 3. 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 Christalin Nelson | SOCS 3 of 44
  • 4. 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 Christalin Nelson | SOCS 4 of 44
  • 5. 16-Apr-24 2-Phase Locking Techniques (2/25) • Types of Locks – Binary Locks – Shared/Exclusive Locks (or Read/Write Lock) – Certify Lock Christalin Nelson | SOCS 5 of 44
  • 6. 16-Apr-24 2-Phase Locking Techniques (3/25) • 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) Christalin Nelson | SOCS 6 of 44
  • 7. 16-Apr-24 2-Phase Locking Techniques (4/25) • Binary Locks (2/3) – 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. Christalin Nelson | SOCS Waiting Queue Not part of lock_item(X) 7 of 44
  • 8. 16-Apr-24 2-Phase Locking Techniques (5/25) • Binary Locks (3/3) – 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) Christalin Nelson | SOCS 8 of 44
  • 9. 16-Apr-24 2-Phase Locking Techniques (6/25) • 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) Christalin Nelson | SOCS 9 of 44
  • 10. 16-Apr-24 Christalin Nelson | SOCS Locking and unlocking operations for two-mode locks 10 of 44
  • 11. 16-Apr-24 2-Phase Locking Techniques (8/25) • Shared/Exclusive Locks (or Read/Write Lock) – 3/5 – 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 Christalin Nelson | SOCS 11 of 44
  • 12. 16-Apr-24 2-Phase Locking Techniques (9/25) • Shared/Exclusive Locks (or Read/Write Lock) – 4/5 – 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 Christalin Nelson | SOCS 12 of 44
  • 13. 16-Apr-24 2-Phase Locking Techniques (10/25) • Shared/Exclusive Locks (or Read/Write Lock) – 5/5 – 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) Christalin Nelson | SOCS 13 of 44
  • 14. 16-Apr-24 2-Phase Locking Techniques (11/25) • 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 Christalin Nelson | SOCS 14 of 44
  • 15. 16-Apr-24 2-Phase Locking Techniques (12/25) • Two-Phase Locking (2/3) – 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’ Christalin Nelson | SOCS 15 of 44
  • 16. 16-Apr-24 2-Phase Locking Techniques (13/25) • Two-Phase Locking (3/3) – 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 Christalin Nelson | SOCS 16 of 44
  • 17. 16-Apr-24 2-Phase Locking Techniques (14/25) • 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 Christalin Nelson | SOCS 17 of 44
  • 18. 16-Apr-24 2-Phase Locking Techniques (15/25) • Variations of Two-Phase Locking (2/3) – 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 Christalin Nelson | SOCS 18 of 44
  • 19. 16-Apr-24 2-Phase Locking Techniques (16/25) • Variations of Two-Phase Locking (3/3) – 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 Christalin Nelson | SOCS 19 of 44
  • 20. 16-Apr-24 2-Phase Locking Techniques (17/25) • 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 Christalin Nelson | SOCS 20 of 44
  • 21. 16-Apr-24 2-Phase Locking Techniques (18/25) • 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 Christalin Nelson | SOCS 21 of 44
  • 22. 16-Apr-24 2-Phase Locking Techniques (19/25) • Deadlock Prevention Protocols (2/4) – (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 Christalin Nelson | SOCS 22 of 44
  • 23. 16-Apr-24 2-Phase Locking Techniques (20/25) • Deadlock Prevention Protocols (3/4) – (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 Christalin Nelson | SOCS 23 of 44
  • 24. 16-Apr-24 2-Phase Locking Techniques (21/25) • Deadlock Prevention Protocols (4/4) – (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. Christalin Nelson | SOCS 24 of 44
  • 25. 16-Apr-24 2-Phase Locking Techniques (22/25) • 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) Christalin Nelson | SOCS A partial schedule of T1’ and T2’ that is in deadlock state WFH for the partial schedule 25 of 44
  • 26. 16-Apr-24 2-Phase Locking Techniques (23/25) • 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 Christalin Nelson | SOCS 26 of 44
  • 27. 16-Apr-24 2-Phase Locking Techniques (24/25) • 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 Christalin Nelson | SOCS 27 of 44
  • 28. 16-Apr-24 2-Phase Locking Techniques (25/25) • 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 Christalin Nelson | SOCS 28 of 44
  • 29. 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) Christalin Nelson | SOCS 29 of 44
  • 30. 16-Apr-24 Concurrency Control Based on Timestamp Ordering (2/5) • 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 Christalin Nelson | SOCS 30 of 44
  • 31. 16-Apr-24 Concurrency Control Based on Timestamp Ordering (3/5) • 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 Christalin Nelson | SOCS 31 of 44
  • 32. 16-Apr-24 Concurrency Control Based on Timestamp Ordering (4/5) • 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 Christalin Nelson | SOCS 32 of 44
  • 33. 16-Apr-24 Concurrency Control Based on Timestamp Ordering (5/5) • 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) Christalin Nelson | SOCS 33 of 44
  • 34. 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 Christalin Nelson | SOCS 34 of 44
  • 35. 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 Christalin Nelson | SOCS 35 of 44
  • 36. 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 Christalin Nelson | SOCS Fine granularity Course granularity 36 of 44
  • 37. 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 Christalin Nelson | SOCS DB system should support multiple levels of granularity 37 of 44
  • 38. 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 Christalin Nelson | SOCS 38 of 44
  • 39. 16-Apr-24 Multiple Granularity Locking (2/6) • 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) Christalin Nelson | SOCS 39 of 44
  • 40. 16-Apr-24 Multiple Granularity Locking (3/6) • 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) Christalin Nelson | SOCS Lock compatibility matrix 40 of 44
  • 41. 16-Apr-24 Multiple Granularity Locking (4/6) • 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 Christalin Nelson | SOCS 41 of 44
  • 42. 16-Apr-24 Christalin Nelson | SOCS 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
  • 43. 16-Apr-24 Multiple Granularity Locking (6/6) • 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 Christalin Nelson | SOCS 43 of 44
  • 44. Thank You Christalin Nelson | SOCS 16-Apr-24 16-Apr-24 44 of 44