Concurrency Control in Distributed Transactions

In a distributed database system, data is stored across multiple sites, and transactions may access data from more than one location at the same time. Concurrency control ensures that multiple transactions running concurrently across different sites do not lead to data inconsistency or conflicts. Transactions in the distributed system are executed in "sets", every set consists of various sub-transactions. These sub-transactions across every node must be executed serially to maintain data integrity & the concurrency control mechanisms do this serial execution.

Types of Concurrency Control Mechanisms

There are 2 types of concurrency control mechanisms as shown below diagram:

1. Pessimistic Concurrency Control (PCC)

Pessimistic Concurrency Control (PCC) is a technique used in database systems to prevent conflicts between concurrent transactions by locking data before it is accessed. It assumes that conflicts are likely to occur, so it blocks other transactions from accessing the data until the current transaction is complete.

This approach ensures high data consistency by preventing issues like dirty reads, lost updates, and unrepeatable reads, but may lead to reduced performance due to blocking and waiting.

Pessimistic Concurrency Control Methods

Following are the four Pessimistic Concurrency Control Methods:

1. Isolation Level

Isolation levels define how strictly transactions are kept isolated from each other to prevent data inconsistencies. Without proper isolation, one transaction may read or modify data while another is still processing it, leading to conflicts.

The four standard isolation levels are:

• Read Uncommitted
• Read Committed
• Repeatable Read
• Serializable

Each level offers a different balance between concurrency and consistency.

2. Two-Phase Locking Protocol

The two-phase locking protocol is a concurrency technique used to manage locks on data items in database. This technique consists of 2 phases:

Growing Phase: The transaction acquires all the locks on the data items that'll be required to execute the transaction successfully. No locks will be realease in this phase.

Shrinking Phase: All the locks acquired in previous phase will be released one by one and No New locks will be acquired in this phase.

3. Distributed Lock Manager

A distributed lock a critical component in the distributed transaction system, which co-ordinates the lock acquiring, and releasing operations in the transactions. It helps in synchronizing the transaction and their operation so that data integrity is maintained.

4. Multiple Granularity Lock

A lock can be acquired at various granular level like: table level, row/record level, page level or any other resource's level. In transaction system a transaction can lock a whole table, or a specific row while performing some changes on it. This lock acquiring when done by various transactions simultaneously, this phenomena is called as multiple granularity locking.

Optimistic Concurrency Control (OCC)

The Optimistic Concurrency control techniques proceeds on the basis of assumption that, 0 or very few transactions will try to access a certain resource simultaneously. We can describe a system as FULLY OPTIMISTIC, if it uses No-Locks at all & checks for conflicts at commit time. It has following 4-phases of operation:

• Read Phase: When a transaction begins, it reads the data while also logging the time-stamp at which data is read to verify for conflicts during the validation phase.
• Execution Phase: In this phase, the transaction executes all its operation like create, read, update or delete etc.
• Validation Phase: Before committing a transaction, a validation check is performed to ensure consistency by checking the last_updated timestamp with the one recorded at read_phase. If the timestamp matches, then the transaction will be allowed to be committed and hence proceed with the commit phase.
• Commit phase: During this phase, the transactions will either be committed or aborted, depending on the validation check performed during previous phase. If the timestamp matches, then transactions are committed else they're aborted.

Optimistic Concurrency Control Methods

Below are four Optimistic Concurrency Control Methods:

1. Timestamp Based (OCC)

In timestamp-based concurrency control, each transaction gets a unique timestamp when it starts. At commit time, if the data was modified by a newer transaction, the current transaction is aborted or restarted based on system policy. If no conflicting updates occurred, the transaction is committed.

Example: Let's say we have two transaction T1 and T2, they operate on data item - A. The Timestamp concurrency technique will keep track of the timestamp when the data was accessed by transaction T1 first time.

Now, let's say this transaction T1 is about to commit, before committing, it will check the initial timestamp with the most recent timestamp. In our case, the transaction T1 won't be committed because a write operations by transaction T2 was performed.

if(Initial_timestamp == Most_recent_timestamp)
then 'Commit'
else
'Abort'

In our case, transaction will be aborted because T2 modified the same data item at 12:15PM.

2. Multi-Version Concurrency Control (MVCC)

In MVCC, every data item has multiple versions of itself. When a transaction starts, it reads the version that is valid at the start of the transaction. And when the transaction writes, it creates a new version of that specific data item. That way, every transaction can concurrently perform their operations.

Example: In a banking system two or more user can transfer money without blocking each other simultaneously.

3. Snapshot Isolation

Snapshot isolation is basically a snapshot stored in an isolated manner when our database system was purely consistent. And this snapshot is read by the transactions at the beginning. Transaction ensures that the data item is not changed while it was executing operations on it. Snapshot isolation is achieved through OCC & MVCC techniques.
Example:

• Transaction T1 reads balance = 1000 and updates it to 800.
• At the same time, T2 also reads balance = 1000 and tries to update it to 900.
• Since T1 commits first, T2 is aborted due to a write-write conflict.

4. Conflict Free Replicated Data Types (CRDTs)

CRDTs is a data structure technique which allows a transaction to perform all its operation and replicate the data to some other node or current node. After all the operations are performed, this technique offers us with merging methods that allows us to merge the data across distributed nodes (conflict-free) and eventually achieving consistent state (eventually consistent property).

Example: Two users edit a shared counter: User A adds 2, and User B adds 3 offline. When they reconnect, a CRDT merges the changes without conflict, resulting in a final value of 5.