Lock Based Protocol in DBMS

The database management system (DBMS) stores data that can connect with one another as well as can be altered at any point. There are instances where more than one user may attempt to access the same data item simultaneously, resulting in concurrency.

As a result, there is a requirement to handle concurrency in order to handle the concurrent processing of transactions across many databases in the picture. Lock-based protocol in DBMS is an example of such an approach.

Let's go through one real-life example which will help us understand the concept of the lock-based protocol in DBMS. Every second, millions of payments take place. Consider buying a movie ticket at your preferred theatre. Now, there's a chance that two or more customers will try to reserve the very same seat without knowing it.

A scenario like this, when treated on a big scale, can damage the database consistency resulting in the corruption of data. To avoid any conflicts over user access to read and write into the database and to ensure that there is no concurrency, each transaction must be handled separately. Lock-based protocols in DBMS are used to accomplish this purpose. To know more about the concept of concurrency, read here: Concurrency control in DBMS

Types of Locks in DBMS

In DBMS Lock based Protocols, there are two modes for locking and unlocking data items Shared Lock (lock-S) and Exclusive Lock (lock-X). Let's go through the two types of locks in detail:

Shared Lock

• Shared Locks, which are often denoted as lock-S(), is defined as locks that provide Read-Only access to the information associated with them. Whenever a shared lock is used on a database, it can be read by several users, but these users who are reading the information or the data items will not have permission to edit it or make any changes to the data items.
• To put it another way, we can say that shared locks don't provide access to write. Because numerous users can read the data items simultaneously, multiple shared locks can be installed on them at the same time, but the data item must not have any other locks connected with it.
• A shared lock, also known as a read lock, is solely used to read data objects. Read integrity is supported via shared locks.
• Shared locks can also be used to prevent records from being updated.
• S-lock is requested via the Lock-S instruction.

Example of Shared Locks: Consider the situation where the value of variable X equals 50 and there are a total of 2 transactions reading X. If one transaction wants to change the value of A, another transaction that tries to read the value will read the incorrect value of the variable X. However, until it is done with reading, the Shared lock stops it from updating.

When the lock-based protocol in DBMS is applied to the transaction (let's say T1) discussed above, all the processes listed below occur.

1. T1 will gain exclusive access to the data item X.
2. Find out what the current value of data item A is.
3. The data item will be accessible once the transaction is finished.

Exclusive Lock

• Exclusive Lock allows the data item to be read as well as written. This is a one-time use mode that can't be utilized on the exact data item twice. To obtain X-lock, the user needs to make use of the lock-x instruction. After finishing the 'write' step, transactions can unlock the data item.
• By imposing an X lock on a transaction that needs to update a person's account balance, for example, you can allow it to proceed. As a result of the exclusive lock, the second transaction is unable to read or write.
• The other name for an exclusive lock is write lock.
• At any given time, the exclusive locks can only be owned by one transaction.

Example of exclusive locks: Consider the instance where the value of a data item X is equal to 50 and a transaction requires a deduction of 20 from the data item X. By putting a Y lock on this particular transaction, we can make it possible. As a result, the exclusive lock prevents any other transaction from reading or writing.

Lock Compatibility Matrix

A vital point to remember when using Lock-based protocols in Database Management System is that a Shared Lock can be held by any amount of transactions. On the other hand, an Exclusive Lock can only be held by one transaction in DBMS, this is because a shared lock only reads data but does not perform any other activities, whereas an exclusive lock performs read as well as writing activities.

The figure given below demonstrates that when two transactions are involved, and both of these transactions seek to read a specific data item, the transaction is authorized, and no conflict occurs; but, in a situation when one transaction intends to write the data item and another transaction attempts to read or write simultaneously, the interaction is rejected.

The two methods outlined below can be used to convert between the locks:

1. Conversion from a read lock to a write lock is an upgrade.
2. Conversion from a write lock to a read lock is a downgrade.

Types of Lock-Based Protocols

There are basically four lock-based protocols in DBMS namely Simplistic Lock Protocol, Pre-claiming Lock Protocol, Two-phase Locking Protocol, and Strict Two-Phase Locking Protocol. Let's go through each of these lock-based protocols in detail.

Simplistic Lock Protocol

The simplistic method is defined as the most fundamental method of securing data during a transaction. Simple lock-based protocols allow all transactions to lock the data before inserting, deleting, or updating it. After the transaction is completed, the data item will be unlocked.

Pre-Claiming Lock Protocol

Pre-claiming Lock Protocols are known to assess transactions to determine which data elements require locks. Prior to actually starting the transaction, it asks the Database management system for all of the locks on all of the data items. The pre-claiming protocol permits the transaction to commence if all of the locks are obtained. Whenever the transaction is finished, the lock is released. This protocol permits the transaction to roll back if all of the locks are not granted and then waits until all of the locks are granted.

Two-phase Locking Protocol

If Locking as well as Unlocking can be performed in 2 phases, a transaction is considered to follow the Two-Phase Locking protocol. The two phases are known as the growing and shrinking phases.

1. Growing Phase: In this phase, we can acquire new locks on data items, but none of these locks can be released.
2. Shrinking Phase: In this phase, the existing locks can be released, but no new locks can be obtained.

Two-phase locking helps to reduce the amount of concurrency in a schedule but just like the two sides of a coin two-phase locking has a few cons too. The protocol raises transaction processing costs and may have unintended consequences. The likelihood of establishing deadlocks is one bad result.

Strict Two-Phase Locking Protocol

In DBMS, Cascaded rollbacks are avoided with the concept of a Strict Two-Phase Locking Protocol. This protocol necessitates not only two-phase locking but also the retention of all exclusive locks until the transaction commits or aborts. The two-phase is with deadlock.

It is responsible for assuring that if 1 transaction modifies data, there can be no other transaction that will be able to read it until the first transaction commits. The majority of database systems use a strict two-phase locking protocol.

Starvation and Deadlock

When a transaction must wait an unlimited period for a lock, it is referred to as starvation. The following are the causes of starvation :

1. When the locked item waiting scheme is not correctly controlled.
2. When a resource leak occurs.
3. The same transaction is repeatedly chosen as a victim.

Let's know how starvation can be prevented. Random process selection for resource or processor allocation should be avoided since it encourages hunger. The resource allocation priority scheme should contain ideas like aging, in which a process' priority rises as it waits longer. This prevents starvation.

Deadlock: In a circular chain, a deadlock situation occurs when two or more processes are expecting each other to release a resource or when more than 2 processes are waiting for the resource.

Read More:

• What is Transaction in DBMS?.