Concept of locking - Binary and Read/Write locks

 


In a Database Management System (DBMS), many transactions may run simultaneously. To prevent conflicts and maintain database consistency, the system uses locking techniques.

A lock controls how transactions access data items so that multiple transactions do not interfere with each other.

The Two-Phase Locking (2PL) protocol is one of the most widely used concurrency control techniques that ensures serializability of schedules.

1. Concept of Locking

A lock is a variable associated with a data item that indicates whether the item is currently being used by a transaction.

Locks are used to synchronize concurrent transactions.

When a transaction wants to access a data item:

  1. It must request a lock.

  2. If the lock is available → access is granted.

  3. If the lock is held by another transaction → the transaction waits.

Locks are managed by a component called the Lock Manager inside the DBMS.

2. Lock Table

The DBMS maintains a lock table that keeps track of all locked data items.

Each entry in the lock table usually contains:

FieldDescription
Data item name        Name of the database item
Lock status        Locked / unlocked or read/write state
Locking transaction        Transaction holding the lock
Waiting queue        Transactions waiting for the item

Only items currently locked appear in the lock table.

3. Types of Locks

Two main locking mechanisms are used:

  1. Binary Locks

  2. Shared/Exclusive (Read/Write) Locks

4. Binary Locks

Binary locking is the simplest locking scheme.

Each data item has a lock that can have two states:

Lock Value    Meaning
0    Unlocked
1    Locked

If an item is locked, no other transaction can access it.

Binary Lock Operations

Two basic operations are used:

1. lock_item(X)

Requests a lock on data item X.

if LOCK(X) = 0
    LOCK(X) ← 1
else
    transaction waits

2. unlock_item(X)

Releases the lock on data item X.

LOCK(X) ← 0
wake up waiting transaction

Rules for Binary Locking

A transaction must follow these rules:

  1. A transaction must issue lock_item(X) before reading or writing X.

  2. A transaction must issue unlock_item(X) after finishing operations on X.

  3. A transaction cannot lock an item it already holds.

  4. A transaction cannot unlock an item it does not hold.

Limitation of Binary Locks

Binary locking is too restrictive because:

  • Only one transaction can access the item at a time

  • Even multiple reads are not allowed simultaneously

Example:

T1 reads X
T2 also wants to read X

Binary locking forces T2 to wait, even though multiple reads are safe.

Therefore, DBMSs use shared/exclusive locks instead.




5. Shared / Exclusive Locks (Read/Write Locks)

This scheme allows multiple transactions to read a data item simultaneously but ensures exclusive access for writing.

There are two types of locks.

1. Shared Lock (Read Lock)

Also called S-lock.

Allows a transaction to read a data item.

Multiple transactions can hold shared locks on the same item at the same time.

Example:

T1 read_lock(X)
T2 read_lock(X)

Both can read X simultaneously.

2. Exclusive Lock (Write Lock)

Also called X-lock.

Allows a transaction to write (update) a data item.

When a transaction holds a write lock:

  • No other transaction can read or write the item.

Example:

T1 write_lock(X)

All other transactions must wait.

6. Lock States

For read/write locking, each item can have three states:

StateMeaning
Unlocked            No transaction holds lock
Read-locked            One or more transactions reading
Write-locked            One transaction writing

7. Locking Operations

Three main operations exist:

OperationPurpose
read_lock(X)        Request shared lock
write_lock(X)        Request exclusive lock
unlock(X)        Release lock

Read Lock Operation

if X is unlocked
    set LOCK(X) = read-locked
    no_of_reads = 1

else if X is already read-locked
    increase number of readers

else
    transaction waits

Write Lock Operation

if X is unlocked
    set LOCK(X) = write-locked

else
    transaction waits

Write locks require exclusive access.

Unlock Operation

When a transaction finishes using X:

if write locked
    set LOCK(X) = unlocked

if read locked
    reduce reader count
    if count = 0
        unlock item

Rules for Shared/Exclusive (Read/Write) Locking Scheme

When a DBMS uses shared (read) locks and exclusive (write) locks, the following rules must be followed by every transaction.

Rule 1: Lock Before Reading

A transaction T must issue a read_lock(X) or write_lock(X) before performing any read operation on the data item X.

Format

read_lock(X) or write_lock(X)
read_item(X)

Meaning

Before reading a data item, the transaction must first acquire a lock on that item.

Rule 2: Write Lock Before Writing

A transaction T must issue a write_lock(X) before performing any write operation on the data item X.

Format

write_lock(X)
write_item(X)

Meaning

Writing requires exclusive access, so a write lock must be obtained before updating the data.

Rule 3: Unlock After Completing Operations

A transaction T must issue unlock(X) after completing all read and write operations on X.

Format

read_item(X) / write_item(X)
unlock(X)

Meaning

Once the transaction finishes using the item, it must release the lock so other transactions can access it.

Rule 4: No Duplicate Read Locks

A transaction cannot issue read_lock(X) if it already holds a read lock or write lock on X.

Meaning

  • A transaction already holding the lock does not need to request it again.

  • This rule can be relaxed for lock downgrading.

Rule 5: No Duplicate Write Locks

A transaction cannot issue write_lock(X) if it already holds a read lock or write lock on X.

Meaning

  • A transaction should not request a write lock if it already holds one.

  • This rule can be relaxed for lock upgrading.

Example of upgrading:

read_lock(X)
write_lock(X)

This converts a shared lock → exclusive lock.

Rule 6: Unlock Only If Lock Exists

A transaction cannot issue unlock(X) unless it currently holds a read or write lock on X.

Meaning

Only the transaction that owns the lock can release it.


8. Lock Conversion

Sometimes a transaction needs to change the type of lock.

This is called lock conversion.

Two types exist.

1. Lock Upgrading

Changing a read lock → write lock.

Example:

read_lock(X)
write_lock(X)

Upgrade is allowed only if no other transaction holds a read lock.

Otherwise the transaction must wait.

2. Lock Downgrading

Changing a write lock → read lock.

Example:

write_lock(X)
read_lock(X)

This allows other transactions to read the item.

9. Limitation of Binary Locks and Read/Write Locks

Using binary locks or shared/exclusive (read/write) locks in transactions does not automatically guarantee serializability of schedules.

Even if all locking rules are followed, a nonserializable schedule may still occur.

Reason for Nonserializable Schedules

This problem occurs when locks are released too early during the execution of a transaction.

Example situation:

  • In Transaction T1, the data item Y is unlocked too early.

  • In Transaction T2, the data item X is also unlocked too early.

Because these locks are released prematurely, other transactions may access and modify the same data items, which can lead to incorrect interleaving of operations.




Resulting Problem

Due to early unlocking:

  • The DBMS may produce a schedule that is not serializable.

  • Such schedules may generate incorrect database results.

Therefore, simply applying locking rules is not sufficient to guarantee correct concurrent execution.

Need for an Additional Protocol

To ensure serializability, the DBMS must enforce an additional rule that controls:

  • When locks can be obtained

  • When locks can be released

This rule governs the proper positioning of locking and unlocking operations within a transaction.

Solution: Two-Phase Locking Protocol

To guarantee serializable schedules, a special protocol called Two-Phase Locking (2PL) is used.

Two-Phase Locking ensures that:

  • Transactions follow a strict pattern of acquiring and releasing locks.

  • Locks are not released too early.

  • The resulting schedules are conflict-serializable.

✅ Key Idea:
Binary locks and read/write locks control access to data items, but without a proper protocol like Two-Phase Locking, they cannot guarantee serializability of concurrent transaction schedules

11. Summary

ConceptDescription
Lock        Mechanism to control access to data
Binary Lock        Two states: locked or unlocked
Shared Lock        Multiple transactions can read
Exclusive Lock        Only one transaction can write
Lock Conversion        Upgrading or downgrading locks
Two-Phase Locking        Protocol ensuring serializability


Comments

Post a Comment

Popular posts from this blog

Database Management Systems DBMS PCCST402 Semester 4 KTU CS 2024 Scheme

 About Me Database Management Systems DBMS PCCST402 Scheme and Syllabus Model Question Paper - KTU BTech DBMS PCCST402 2024 Scheme Module-1 Introduction to DBMS Introduction to DBMS Example  Database Database System Vs Traditional File Processing Advantages of using DBMS Database System Concepts and Architecture Data Models, Schemas and Instances   Three schema architecture and Data Independence Database Languages and Interfaces Centralized and Client Server Architectures in DBMS Classification of Database Management Systems Conceptual Data Modeling and Database Design Conceptual Modeling and the Role of the ER Model in Database Design Entities and Attributes  Company Database Application - Example Entity Types, Entity Sets, Keys, and Value Sets in the ER Model Initial Conceptual Design of the COMPANY Database Relationship Types in the ER Model Relationship Degree, Role Names, and Recursive Relationships Constraints on Binary Relationship Types Attributes of Relation...
Read more

Data Models, Schemas and Instances

  Data Models, Schemas and Instances  1. Data Abstraction In databases, data abstraction means hiding the complex details of how data is stored and focusing only on what is important. Different users can view data at different levels of detail depending on their needs. 2. Data Models A data model is a collection of concepts used to describe the structure of a database. It defines: Data types Relationships among data Constraints on data Operations for accessing and updating data Data models help us understand and design databases without worrying about low-level storage details. Categories of Data Models a) High-level / Conceptual Data Models Close to how users think about data. Use concepts like entities , attributes , and relationships . Example: ER (Entity–Relationship) Model . b) Representational (Implementation) Data Models In between conceptual and physical models. Easy for users to understand but still close to how data is st...
Read more

Introduction to Database Management System -DBMS

Image
In today’s digital world, almost every application—from mobile banking and e-commerce to university portals and hospital systems—depends on the efficient storage, organization, and retrieval of data. As the amount of information generated by individuals and organizations continues to grow, managing this data in a structured and meaningful way becomes essential. This is where database systems play a central role. A database can be thought of as a well-organized collection of related data, designed so that it can be easily accessed, managed, and updated. But the database itself is only one component. To manage it effectively, we rely on a specialized software package known as a Database Management System (DBMS) . A DBMS provides a systematic and automated way to store large volumes of data, enforce rules for consistency and correctness, protect data from unauthorized access, and allow multiple users to work with the data simultaneously without conflicts. A database typically has three...
Read more