Lock-Based Protocol

Lock-Based Protocol

In database systems, concurrency control plays a crucial role in ensuring consistency and isolation when multiple transactions are executed simultaneously. One of the most widely used techniques for concurrency control is the Lock-Based Protocol.

In this protocol, a transaction cannot read or write a data item until it successfully acquires the required lock on it. Locks are essential in preventing problems like lost updates, temporary inconsistency, or uncommitted data access.

Machine Learning Tutorial:–Click Here
Data Science Tutorial:-Click Here
Complete Advance AI topics:- CLICK HERE
Deep Learning Tutorial:- Click Here

What is a Lock?

A lock is a mechanism associated with each data item that represents the item’s state with respect to possible operations. By manipulating lock values, a system can manage concurrent access and ensure that no conflicting operations are executed at the same time.

When a transaction locks a data item, it prevents other transactions from accessing it until the lock is released. This ensures serialization of concurrent transactions and maintains database consistency.

Types of Locks

Locks can be classified into multiple categories depending on how they restrict access to data.

1. Binary Locks

A binary lock is the simplest form of lock and has only two states:

• Locked (1)
• Unlocked (0)

Each data item has a separate lock. If a transaction locks a data item, no other transaction can access it until it is unlocked.

Two main operations are associated with binary locking of a data item A:

• Lock(A): Issued before a read or write operation.
• Unlock(A): Issued after the transaction has finished using the data item.

Rules for Binary Locking:

• A lock must be acquired before reading or writing a data item.
• A transaction must release the lock after completing operations.
• A lock cannot be released unless it is held by the transaction.
• A transaction cannot re-lock a data item it already holds.

Example – Lost Update Problem Solved with Binary Locks:

Without locks, if two transactions update an account simultaneously, updates may be lost. By using binary locks, one transaction must wait until the other releases the lock, ensuring serializability.

2. Shared and Exclusive Locks

Binary locks are simple but have limited usage. In practice, databases use shared and exclusive locks, also known as read/write locks.

• Shared Lock (S-lock):
  • Also called a read lock.
  • Multiple transactions can hold a shared lock on the same item.
  • Allows read-only operations but prevents modifications.
• Exclusive Lock (X-lock):
  • Allows both read and write operations.
  • Only one transaction can hold an exclusive lock at a time.

Rules for Shared/Exclusive Locks:

• A lock must be acquired before any read/write operation.
• Exclusive locks are required before updates.
• A transaction must release its locks after finishing.
• No transaction can request a lock type it already holds.

Lock Compatibility Matrix:

This matrix ensures that multiple shared locks can coexist, but exclusive locks remain truly exclusive.

Example: Inconsistent Read Problem

Consider two accounts A (1000) and B (900).

• Transaction T1 transfers Rs. 200 from A to B.
• Transaction T2 calculates the sum of balances in A and B.

If locks are not managed properly, T2 might read A before and B after T1’s modification, producing an incorrect sum. This illustrates that while locks prevent conflicts, they do not fully eliminate all concurrency issues.

Lock-Based Protocols

Different lock protocols are designed to manage transactions more effectively.

1. Simplistic Lock Protocol

• Transactions acquire locks before read/write operations.
• Locks are released only after the transaction completes.
• Simple but can lead to deadlocks.

2. Pre-Claiming Lock Protocol

• A transaction requests all required locks before execution.
• If all locks are available, execution starts.
• If not, the transaction waits or rolls back.
• Reduces deadlocks but increases waiting time.

3. Two-Phase Locking Protocol (2PL)

This is the most widely used protocol. It divides execution into two phases:

• Growing Phase: Transaction acquires all required locks but cannot release any.
• Shrinking Phase: Transaction releases locks but cannot acquire new ones.

This ensures serializability. Lock conversion is also possible:

• Upgrade: From Shared (S) to Exclusive (X) during growing phase.
• Downgrade: From Exclusive (X) to Shared (S) during shrinking phase.

Example:

• Transaction T1 locks items in steps 1–3 (growing phase) and releases them in steps 5–7 (shrinking phase).
• Transaction T2 follows a similar pattern with its own lock point.

4. Strict Two-Phase Locking Protocol (Strict-2PL)

• Similar to 2PL but stricter.
• Locks are not released until the transaction commits.
• Prevents cascading rollbacks.
• Ensures a higher level of consistency but can increase waiting times.

Complete Python Course with Advance topics:-Click Here
SQL Tutorial :–Click Here
Download New Real Time Projects :–Click here

Final Thoughts

Lock-based protocols are at the heart of concurrency control in database systems. They prevent problems like lost updates, uncommitted reads, and inconsistent states. However, while locks enforce serializability, they may introduce challenges such as deadlocks or longer waiting times.

Choosing the right lock protocol depends on the application’s requirements—whether it prioritizes speed, consistency, or fault tolerance.

For more deep-dive articles on Database Management Systems, stay connected with UpdateGadh.

lock based protocol in dbms
lock based protocol example
timestamp based protocol in dbms
types of lock based protocol in dbms
lock based protocol pdf
lock-based protocol in dbms ppt
validation based protocol in dbms
two phase locking protocol in dbms