Do you think IIT Guwahati certified course can help you in your career?
Introduction
Hello Ninja, I hope you are doing great. Do you know about MOSS Concurrency Control Protocol? If not, don't worry. We are here to enrich your knowledge and clear all your doubts. The MOSS Concurrency Control Protocol is a locking protocol that is used to handle nested transactions. In this article, we will cover this protocol in detail.
This article will discuss the Concurrency Control in Database Systems and the Nested Transaction model. We will mainly focus on the locking schemes and the locking rules of the MOSS Concurrency Control Protocols with their further extensions.
What is Concurrency Control in Database Systems?
It is a technique that helps manage the data when multiple transactions or operations happen simultaneously. Let's assume we have a Database where we can all read or update the data simultaneously. This mechanism makes sure that these actions won’t interfere with each other and our data remains consistent. Without a Concurrency Control, our updates may cause conflict and inconsistencies in the data. One widely used Concurrency Control technique is locking, in which we give a temporary key to the person who wants to change the data, which prevents conflicts by not allowing others to interfere in between.
A transaction may contain any number of subtransactions, which again may be composed of further subtransactions resulting in a deep hierarchy of nested transactions. The root transaction (which is not enclosed by any transaction) is called a top-level transaction (TL transaction). Transactions with subtransactions are called parents and these subtractions are called children. We can represent a hierarchy of TL-transaction by a transaction tree given below.
The nodes of the tree are representing the transactions and the edges of the tree are representing the parent-children relationships. The nested transaction supports intra-transaction parallelism which is the ability to execute subtransactions concurrently within a single transaction.
In a nested transaction model, we have four levels of intra-transaction parallelism.
Neither parent-child nor sibling parallelism:At this point, at most, one active transaction is available in the TL-translation hierarchy. All the transactions will execute serially, so no concurrency control is required.
Only sibling parallelism: Here, only the sibling transactions are performed concurrently, the transaction never runs in parallel with its ancestor. The transactions may share their resources with their ancestors without concurrency control.
Only parent-child parallelism: Here, only the transactions with their parents may run concurrently but the siblings may not. In a TL-transaction hierarchy, the transactions along one path of the hierarchy may run in parallel.
Sibling as well as parent-child parallelism: In this type of parallelism, any transactions can run in parallel, whether they have a sibling or a parent-child relationship. All the transactions in a TL-transactions hierarchy may run concurrently. It has the highest degree of parallelism, requiring the most optimized concurrent control scheme.
MOSS Concurrency Control Protocol
The MOSS Concurrency Control Protocol controls the parallelism in distributed Database Systems and handles nested transactions. The locking scheme for the nested transactions is based on this protocol. This scheme only allows for the upward inheritance of locks, i.e., a transaction can inherit locks from its children but not vice versa. But we can also extend this scheme to support upward and downward inheritance. Let’s discuss all its schemes and the locking rules.
Upward Inheritance of Locks
The possible lock modes for an object are NL-mode, S-mode, and X-mode. The NL mode or null mode represents the absence of a lock request for a lock on the object. A transaction can acquire a lock on an object in some mode ‘M’ and holds the lock in mode ‘M’ until its termination. When a subtransaction commits, its parent transaction inherits its lock and then retains them. If a transaction holds a lock, it has access to the lock object, but if it retains the lock, it is impossible to access the lock object. A retained lock of the X-mode shows that the transactions outside the hierarchy of the retainer can’t acquire the lock, but the descendants can acquire a lock. If a transaction retains an X-lock, it means the transactions outside the hierarchy can’t hold the lock in the X-mode or S-mode, but if a transaction retains an S-lock, the transactions outside the hierarchy can hold the lock in the S-mode.
Locking Rules for the MOSS Concurrency Control Protocol
Rule 1: The transaction (T) may require a lock in X-mode if there is no transaction holding the lock in the X-mode or S-mode or the ancestors of T are holding the locks in the S-mode or X-mode.
Rule 2: The transaction (T) may require a lock in the S-mode if no transaction holds a lock in the X-mode or the ancestors of T are holding the locks in the X-mode.
Rule 3: When the transaction of T commits, the parent of T inherits the locks and retains them in the same mode.
Rule 4: When a transaction aborts, it releases all the locks it retains or holds. If any of its ancestors retains or holds the same lock, they continue to do so.
Controlled Downward Inheritance
We can control the lock mode in which inferiors can access an offered object. Let's assume we have transaction A, which generates object O (describing the interface of a workpiece), and transactions B and C are the children of transaction A as shown in the image above. If B and C design the subparts of the workpiece, they require access to the interface description. To allow its children to read the object, transaction A must offer the lock to its children. If the children acquire the lock in the X-mode, they can change the object and prevent other siblings from reading it, which may cause trouble. To overcome these problems, we can replace the lock-offering mechanism with primitives supporting the upgrading and downgrading of locks.
Downgrading a lock in Controlled Downward Inheritance
The transaction, holding a lock in mode M, can downgrade the lock to a less restrictive mode M*, so that the transaction holds the lock in mode M* and retains it in mode M. It prevents the transactions outside its hierarchy from holding a lock in a mode conflicting with M but allows its inferiors to hold the lock in mode M*.
Upgrading a lock in Controlled Downward Inheritance
The transaction (T), holding a lock in mode M, can upgrade the lock to a more restrictive mode M*. After upgrading the lock, no other transaction will hold the lock in a mode conflicting with M* and only the ancestors of the transaction will retain the lock in a mode conflicting with M*.
Extensions added to the rules of MOSS Concurrency Control Protocol
Rule 1: The transaction (T) may require a lock in X-mode or upgrade a lock it holds to the X-mode if there is no transaction holding the X-mode or S-mode or the ancestors of T are holding the locks in the S-mode or X-mode.
Rule 2:The transaction (T) may require a lock in the S-mode if no transaction holds a lock in the X-mode or the ancestors of T are holding the locks in the X-mode.
Rule 3: When a subtransaction of T commits, the parent of T inherits its locks and retains them in the same mode./
Rule 4: when a top-level transaction commits, it releases all the locks it holds or retains.
Rule 5: When a transaction aborts, it releases all the locks it retains or holds. If any of its ancestors retains or holds the same lock, they continue to do so.
Rule 6: The transaction (T), holding a lock in X-mode, can downgrade the lock to S-mode or NL-mode. After performing the downgrading operation, T retains the lock in X-mode.
Rule 7: The transaction (T), holding a lock in S-mode, can downgrade the lock in NL-mode and then retains the lock in the S-mode.
How does the nested transaction tree represent the hierarchy of nested transactions?
In a nested transaction tree, the node represents a transaction, and the relationship between transactions is depicted through parent-child connections. The tree's root represents the top-level transaction, and the subsequent transactions are considered child nodes nested with their parent transactions.
What are the problems associated with the MOSS Concurrency Control Protocol?
The problems associated with the MOSS Concurrency Control Protocol are lock conflicts, deadlocks, locking overhead, increased waiting time and reduced concurrency.
Why do we downgrade or upgrade a lock in controlled downward inheritance?
We downgrade or upgrade a lock so that the children can’t change the parent object, and if reading access is provided to the children, then every sibling can read the object.
569+ registered 
