Flat & Nested Distributed Transactions :

If a client transaction calls actions on multiple servers, it is said to be distributed.

Distributed transactions can be structured in two different ways:
1. Flat transactions
2. Nested transactions

FLAT TRANSACTIONS :
A flat transaction has a single initiating point(Begin) and a single end point(Commit or
abort). They are usually very simple and are generally used for short activities rather than
larger ones.
A client makes requests to multiple servers in a flat transaction. Transaction T, for
example, is a flat transaction that performs operations on objects in servers X, Y, and Z.
Before moving on to the next request, a flat client transaction completes the previous one.
As a result, each transaction visits the server object in order.
A transaction can only wait for one object at a time when servers utilize locking.

Flat Transaction

Limitations of a flat Transaction :

 All work is lost in the event of a crash.
 Only one DBMS may be used at a time.
 No partial rollback is possible.
NESTED TRANSACTIONS :
A transaction that includes other transactions within its initiating point and a end point are
known as nested transactions. So the nesting of the transactions is done in a transaction.
The nested transactions here are called sub-transactions.
The top-level transaction in a nested transaction can open sub-transactions, and each
sub-transaction can open more sub-transactions down to any depth of nesting.
A client’s transaction T opens up two sub-transactions, T1 and T2, which access objects
 on servers X and Y, as shown in the diagram below.
T1.1, T1.2, T2.1, and T2.2, which access the objects on the servers M,N, and P, are
opened by the sub-transactions T1 and T2.

Nested Transaction

Concurrency Control in Distributed Transactions

Last Updated : 17 Apr, 2024





Concurrency control mechanisms provide us with various concepts &

implementations to ensure the execution of any transaction across any node
doesn't violate ACID or BASE (depending on database) properties causing
inconsistency & mixup of data in the distributed systems. 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:
Types of Concurrency Control Mechanism
Pessimistic Concurrency Control (PCC)
The Pessimistic Concurrency Control Mechanisms proceeds on assumption that,
most of the transactions will try to access the same resource simultaneously. It's
basically used to prevent concurrent access to a shared resource and provide a
system of acquiring a Lock on the data item before performing any operation.
Optimistic Concurrency Control (OCC)
The problem with pessimistic concurrency control systems is that, if a
transaction acquires a lock on a resource so that no other transactions can
access it. This will result in reducing concurrency of the overall system.
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.
Pessimistic Concurrency Control Methods
Following are the four Pessimistic Concurrency Control Methods:
Isolation Level
The isolation levels are defined as a degree to which the data residing
in Database must be isolated by transactions for modification. Because, if some
transactions are operating on some data let's say transaction - T1 & there
comes another transaction - T2 and modifies it further while it was under
operation by transaction T1 this will cause unwanted inconsistency problems.
Methods provided in this are: Read-Uncomitted, Read-
Comitted, Repeatable Read & Serializable.
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.

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.
Distributed Lock Manager (DLM)

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 Methods
Below are four Optimistic Concurrency Control Methods:
Timestamp Based (OCC)
In a timestamp based concurrency technique, each transaction in the system is
assigned a unique timestamp which is taken as soon as the transaction begins,
and its verified again during the commit phase. If there's new updated
timestamp from a different transaction then based on some policy defined by
the System Adminstrator the transaction will either be restarted or aborted. But
if the times stamp is same & never modified by any other transaction then it will
be 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.
 Data item and Initial_timestamp of
Transaction operation Most_recent_Timestamp data item (A)

T1 Read(A) 12:00PM 12:00PM

T2 Write(A) 12:15PM 12:00PM

T1 Write(A) 12:30PM 12:00PM

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.

What is Timestamp Ordering Protocol?

The main idea for this protocol is to order the transactions based on their Timestamps. A
schedule in which the transactions participate is then serializable and the only equivalent
serial schedule permitted has the transactions in the order of their Timestamp Values.
Stating simply, the schedule is equivalent to the particular Serial Order corresponding to
the order of the Transaction timestamps. An algorithm must ensure that, for each item
accessed by Conflicting Operations in the schedule, the order in which the item is
accessed does not violate the ordering. To ensure this, use two Timestamp Values
relating to each database item X.
 W_TS(X) is the largest timestamp of any transaction that
executed write(X) successfully.
 R_TS(X) is the largest timestamp of any transaction that
executed read(X) successfully.
Basic Timestamp Ordering
Every transaction is issued a timestamp based on when it enters the system. Suppose, if
an old transaction T i has timestamp TS(Ti), a new transaction T j is assigned timestamp
TS(Tj) such that TS(Ti) < TS(Tj). The protocol manages concurrent execution such that
the timestamps determine the serializability order. The timestamp ordering protocol
ensures that any conflicting read and write operations are executed in timestamp order.
Whenever some Transaction T tries to issue a R_item(X) or a W_item(X), the Basic TO
algorithm compares the timestamp of T with R_TS(X) & W_TS(X) to ensure that the
Timestamp order is not violated. This describes the Basic TO protocol in the following two
cases.
 Whenever a Transaction T issues a W_item(X) operation, check the following
conditions:
o If R_TS(X) > TS(T) and if W_TS(X) > TS(T), then abort and rollback T and
reject the operation. else,
o Execute W_item(X) operation of T and set W_TS(X) to TS(T).
 Whenever a Transaction T issues a R_item(X) operation, check the following
conditions:
o If W_TS(X) > TS(T), then abort and reject T and reject the operation, else
 o If W_TS(X) <= TS(T), then execute the R_item(X) operation of T and set
R_TS(X) to the larger of TS(T) and current R_TS(X).

Whenever the Basic TO algorithm detects two conflicting operations that occur in an
incorrect order, it rejects the latter of the two operations by aborting the Transaction that
issued it. Schedules produced by Basic TO are guaranteed to be conflict serializable.
Already discussed that using Timestamp can ensure that our schedule will be deadlock
free.
One drawback of the Basic TO protocol is that Cascading Rollback is still possible.
Suppose we have a Transaction T 1 and T2 has used a value written by T 1. If T1 is aborted
and resubmitted to the system then, T 2 must also be aborted and rolled back. So the
problem of Cascading aborts still prevails. Let’s gist the Advantages and Disadvantages of
Basic TO protocol:
 Timestamp Ordering protocol ensures serializability since the precedence graph will be
of the form:

Precedence Graph for TS ordering

 Timestamp protocol ensures freedom from deadlock as no transaction ever waits.
 But the schedule may not be cascade free, and may not even be recoverable.
Strict Timestamp Ordering
A variation of Basic TO is called Strict TO ensures that the schedules are both Strict and
Conflict Serializable. In this variation, a Transaction T that issues a R_item(X) or
W_item(X) such that TS(T) > W_TS(X) has its read or write operation delayed until the
Transaction T‘ that wrote the values of X has committed or aborted.
Advantages of Timestamp Ordering Protocol
 High Concurrency: Timestamp-based concurrency control allows for a high degree of
concurrency by ensuring that transactions do not interfere with each other.
 Efficient: The technique is efficient and scalable, as it does not require locking and
can handle a large number of transactions.
 No Deadlocks: Since there are no locks involved, there is no possibility
of deadlocks occurring.
 Improved Performance: By allowing transactions to execute concurrently, the overall
performance of the database system can be improved.
Disadvantages of Timestamp Ordering Protocol
 Limited Granularity: The granularity of timestamp-based concurrency control is
limited to the precision of the timestamp. This can lead to situations where transactions
are unnecessarily blocked, even if they do not conflict with each other.
 Timestamp Ordering: In order to ensure that transactions are executed in the correct
order, the timestamps need to be carefully managed. If not managed properly, it can
lead to inconsistencies in the database.
 Timestamp Synchronization: Timestamp-based concurrency control requires that all
transactions have synchronized clocks. If the clocks are not synchronized, it can lead
to incorrect ordering of transactions.
 Timestamp Allocation: Allocating unique timestamps for each transaction can be
challenging, especially in distributed systems where transactions may be initiated at
different locations.

What is Replication in Distributed Systems?

Replication in distributed systems refers to the process of creating and maintaining
multiple copies (replicas) of data, resources, or services across different nodes
(computers or servers) within a network. The primary goal of replication is to enhance
system reliability, availability, and performance by ensuring that data or services are
accessible even if some nodes fail or become unavailable.
Importance of Replication in Distributed Systems
Replication plays a crucial role in distributed systems due to several important reasons:
 Enhanced Availability:
o By replicating data or services across multiple nodes in a distributed system,
you ensure that even if some nodes fail or become unreachable, the system
as a whole remains available.
o Users can still access data or services from other healthy replicas, thereby
improving overall system availability.
 Improved Reliability:
o Replication increases reliability by reducing the likelihood of a single point of
failure.
o If one replica fails, others can continue to serve requests, maintaining system
operations without interruption.
o This redundancy ensures that critical data or services are consistently
accessible.
 Reduced Latency:
o Replicating data closer to users or clients can reduce latency, or the delay in
data transmission.
o This is particularly important in distributed systems serving users across
different geographic locations.
o Users can access data or services from replicas located nearer to them,
improving response times and user experience.
 Scalability:
o Replication supports scalability by distributing the workload across multiple
nodes.
o As the demand for resources or services increases, additional replicas can
be deployed to handle increased traffic or data processing requirements.
 o This elasticity ensures that distributed systems can efficiently handle varying
workloads.
Types of Replication in Distributed Systems
Below are the types of replication in distributed systems:
1. Primary-Backup Replication
Primary-Backup Replication (also known as active-passive replication) involves
designating one primary replica (active) to handle all updates (writes), while one or more
backup replicas (passive) maintain copies of the data and synchronize with the primary.
 Advantages:
o Strong Consistency: Since all updates go through the primary replica, read
operations can be served with strong consistency guarantees.
o Fault Tolerance: If the primary replica fails, one of the backup replicas can
be promoted to become the new primary, ensuring continuous availability.
 Disadvantages:
o Latency for Reads: Read operations might experience latency because they
might need to wait for updates to propagate from the primary to the backup
replicas.
o Resource Utilization: Backup replicas are often idle unless a failover
occurs, which can be seen as inefficient resource utilization.
 Use Cases:
o Primary-Backup replication is commonly used in scenarios where strong
consistency and fault tolerance are critical, such as in relational databases
where data integrity and availability are paramount.
2. Multi-Primary Replication
Multi-Primary Replication allows multiple replicas to accept updates independently. Each
replica acts as both a client (accepting updates) and a server (propagating updates to
other replicas).
 Advantages:
o Increased Write Throughput: Multiple replicas can handle write requests
concurrently, improving overall system throughput.
o Lower Write Latency: Writes can be processed locally at each replica,
reducing the latency compared to centralized primary-backup models.
o Fault Tolerance: Even if one replica fails, other replicas can continue to
accept writes and serve read operations.
 Disadvantages:
o Conflict Resolution: Concurrent updates across multiple primaries can lead
to conflicts that need to be resolved, typically using techniques like conflict
detection and resolution algorithms (e.g., timestamp ordering or version
vectors).
o Consistency Management: Ensuring consistency across all replicas can be
complex, especially in distributed environments with network partitions or
communication delays.
 Use Cases:
o Multi-Primary replication is suitable for applications requiring high write
throughput and low latency, such as collaborative editing systems or
distributed databases supporting globally distributed applications.
3. Chain Replication
 Chain Replication involves replicating data sequentially through a chain of nodes. Each
node in the chain forwards updates to the next node in the sequence, typically ending with
a return path to the primary node.
 Advantages:
o Strong Consistency: Chain replication can provide strong consistency
guarantees because updates propagate linearly through the chain.
o Fault Tolerance: If a node fails, the chain can still operate as long as there
are enough operational nodes to maintain the chain structure.
 Disadvantages:
o Performance Bottlenecks: The overall performance of the system can be
limited by the slowest node in the chain, as each update must traverse
through every node in sequence.
o Latency: The length of the chain and the propagation time between nodes
can introduce latency for updates.
 Use Cases:
o Chain replication is often used in systems where strong consistency and fault
tolerance are critical, such as in distributed databases or replicated state
machines where linearizability is required.
4. Distributed Replication
Distributed Replication distributes data or services across multiple nodes in a less
structured manner compared to primary-backup or chain replication. Replicas can be
located geographically or logically distributed across the network.
 Advantages:
o Scalability: Distributed replication supports horizontal scalability by allowing
replicas to be added or removed dynamically as workload demands change.
o Fault Tolerance: Redundancy across distributed replicas enhances fault
tolerance and system reliability.
 Disadvantages:
o Consistency Challenges: Ensuring consistency across distributed replicas
can be challenging, especially in environments with high network latency or
partition scenarios.
o Complexity: Managing distributed replicas requires robust synchronization
mechanisms and conflict resolution strategies to maintain data integrity.
 Use Cases:
o Distributed replication is commonly used in large-scale distributed systems,
cloud computing environments, and content delivery networks (CDNs) to
improve scalability, fault tolerance, and performance.
5. Synchronous vs. Asynchronous Replication
 Description:
o Synchronous Replication: In synchronous replication, updates are
committed to all replicas before acknowledging the write operation to the
client. This ensures strong consistency but can introduce latency as the
system waits for all replicas to confirm the update.
o Asynchronous Replication: In asynchronous replication, updates are
propagated to replicas after the write operation is acknowledged to the client.
This reduces latency but may lead to eventual consistency issues if replicas
fall behind or if there is a failure before updates are fully propagated.
 Advantages and Disadvantages:
 o Synchronous: Provides strong consistency and ensures that all replicas are
up-to-date, but can increase latency and vulnerability to failures.
o Asynchronous: Reduces latency and improves performance but sacrifices
immediate consistency and may require additional mechanisms to handle
potential data inconsistencies.
 Use Cases:
o Synchronous replication is suitable for applications where strong consistency
and data integrity are paramount, such as financial transactions or critical
database operations.
o Asynchronous replication is often used in scenarios where lower latency and
higher throughput are prioritized, such as in content distribution or non-critical
data replication.
Benefits of Replication in Distributed Systems
Below are the benefits of replication in distributed systems:
 Enhanced Availability:
o Replication ensures that data or services are accessible even if some nodes
fail or become unavailable.
o Users can access replicated data from other available nodes, reducing
downtime and improving system reliability.
 Improved Performance:
o By distributing replicas geographically or logically closer to users, replication
reduces latency for accessing data or services.
o This improves response times and enhances overall system performance,
especially in globally distributed environments.
 Scalability:
o Replication supports horizontal scalability by distributing the workload across
multiple nodes.
o Additional replicas can be added to handle increased traffic or processing
demands, ensuring that the system can grow to accommodate growing user
demands.
 Fault Tolerance:
o Replication provides fault tolerance by creating redundant copies of data or
services.
o If one replica fails or experiences issues, other replicas can continue to serve
requests, maintaining system operations without interruption.
 Load Balancing:
o Distributing replicas helps balance the workload across nodes, preventing
any single node from becoming overwhelmed with requests.
o This ensures efficient resource utilization and improves overall system
performance.
Challenges and Considerations of Replication in Distributed
Systems
Below are the challenges and consideration of Replication in Distributed Systems:
 Consistency Management:
o Maintaining consistency across replicas is a fundamental challenge in
replication.
 o Different consistency models (e.g., strong consistency, eventual consistency)
have trade-offs between consistency guarantees and performance.
o Implementing consistency mechanisms and handling conflicts due to
concurrent updates can be complex.
 Synchronization Overhead:
o Replicating data or services requires synchronization mechanisms to ensure
that updates are propagated correctly and consistently across replicas.
o Synchronization overhead, including network latency and communication
costs, can impact system performance.
 Complexity of Implementation:
o Designing and implementing replication strategies can be complex, especially
in large-scale distributed systems.
o Factors such as replica placement, data partitioning, and fault detection
mechanisms need careful consideration to ensure effective replication
management.
 Network Partitioning:
o Network partitions or communication failures between replicas can lead to
inconsistencies and divergence in data states.
o Handling network partitions and ensuring data integrity across distributed
replicas require robust fault detection and recovery mechanisms.
 Consistency-Performance Trade-offs:
o Different consistency models (e.g., strong consistency vs. eventual
consistency) involve trade-offs between data consistency and system
performance.
o Choosing the appropriate consistency model depends on application
requirements, such as data integrity and response time expectations.

What is Group Communication in Distributed Systems?

Group communication in distributed systems refers to the process where multiple nodes
or entities communicate with each other as a group.
 Instead of sending messages to individual recipients, group communication allows a
sender to transmit information to all members of a group simultaneously.
 This method is essential for coordinating actions, sharing data, and ensuring that all
participants in the system are informed and synchronized. It’s particularly useful in
scenarios like collaborative applications and real-time updates.
Importance of Group Communication in Distributed Systems
Group communication is critically important in distributed systems due to several key
reasons:
 Multiple nodes must collaborate and synchronize their actions. Group communication
helps them exchange information and stay updated.
 Different nodes can create data that needs to be shared. Group communication helps
quickly send this information to everyone involved, reducing delays and keeping data
consistent.
 Group communication protocols enhance reliability by allowing messages to be
replicated or acknowledged across multiple nodes. This ensures robust
communication, even during failures or network issues.
 As distributed systems expand, effective scaling is crucial. Group communication
mechanisms can manage more nodes and messages without sacrificing performance,
keeping the system efficient and responsive.
Types of Group Communication in a Distributed System
Below are the three types of group communication in distributed systems:
1. Unicast Communication

Unicast Communication

Unicast communication is the point-to-point transmission of data between two nodes in a

network. In the context of distributed systems:
 Unicast is when a sender sends a message to a specific recipient, using their unique
network address.
 Each message targets one recipient, creating a direct connection between the sender
and the receiver.
 You commonly see unicast in client-server setups, where a client makes requests and
receives responses, as well as in direct connections between peers.
 This method makes good use of network resources, is easy to implement, and keeps
latency low because messages go straight to the right person.
 Unicast isn’t efficient for sending messages to many recipients at once, as it requires
separate messages for each one, leading to more work.
2. Multicast Communication
 Multicast Communication

Multicast communication involves sending a single message from one sender to multiple
receivers simultaneously within a network. It is particularly useful in distributed systems
where broadcasting information to a group of nodes is necessary:
 Multicast lets a sender share a message with a specific group of people who want it.
 This way, the sender can reach many people at once, which is more efficient than
sending separate messages.
 This approach is often used to send updates to subscribers or in collaborative
applications where real-time sharing of changes is needed.
 By sending data just once to a group, multicast saves bandwidth, simplifies
communication, and can easily handle a larger number of recipients.
 Managing group membership is necessary to ensure reliable message delivery, and
multicast can run into issues if there are network problems that affect everyone in the
group.
3. Broadcast Communication
Broadcast communication involves sending a message from one sender to all nodes in
the network, ensuring that every node receives the message:
 Broadcast Communication

 Broadcast is when a sender sends a message to every node in the network without
targeting specific recipients.
 Messages are delivered to all nodes at once using a special address designed for this
purpose.
 It’s often used for network management tasks, like sending status updates, or for
emergency alerts that need to reach everyone quickly.
 Broadcast ensures that every node receives the message without needing to specify
who the recipients are, making it efficient for sharing information widely.
 It can cause network congestion in larger networks and raises security concerns since
anyone on the network can access the broadcast message, which might lead to
unauthorized access.
Reliable Multicast Protocols for Group Communication
Messages sent from a sender to multiple recipients should be delivered reliably,
consistently, and in a specified order. Types of Reliable Multicast Protocols include:
 FIFO Ordering:
o Ensures that messages are delivered to all group members in the order they
were sent by the sender.
o Achieved by sequencing messages and delivering them sequentially to
maintain the correct order.
 Causal Ordering:
o Preserves the causal relationships between messages based on their
dependencies.
 o Ensures that messages are delivered in an order that respects the causal
dependencies observed by the sender.
 Total Order and Atomicity:
o Guarantees that all group members receive messages in the same global
order.
o Ensures that operations based on the multicast messages (like updates to
shared data) appear atomic or indivisible to all recipients.
Scalability for Group Communication
Scalability and performance are vital for effective group communication in distributed
systems. It’s essential for the system to handle more nodes, messages, and participants
while still operating efficiently. Here’s a closer look at these important aspects:
1. Scalability
Scalability refers to the system’s ability to grow without losing efficiency. This includes:
 Managing an increasing number of nodes or participants while keeping communication
smooth.
 Handling more messages exchanged among group members, ensuring timely and
responsive communication.
 Supporting connections across distant nodes or networks, which can introduce latency
and bandwidth issues.
2. Challenges in Scalability
As the group size grows, several challenges arise:
 The management of group membership and message routing becomes more complex,
adding overhead.
 The network must have enough bandwidth to support the higher traffic from a larger
group to avoid congestion.
 Keeping distributed nodes consistent and synchronized gets more complicated as the
system scales.
3. Strategies for Scalability
To tackle these challenges, various strategies can be employed:
 Partitioning and Sharding: Breaking the system into smaller parts can make
communication and management more manageable.
 Load Balancing: Evenly distributing the workload across nodes helps prevent
bottlenecks and optimizes resource use.
 Replication and Caching: Duplicating data or messages across nodes can lower
access times and enhance fault tolerance, aiding scalability.
Performance for Group Communication
Performance in group communication is crucial for optimizing message speed, resource
utilization, and addressing challenges like message ordering and concurrent access,
ensuring efficient collaboration in distributed systems.
1. Performance
In group communication, performance focuses on a few key areas:
 It’s crucial to minimize the time it takes for messages to reach their intended recipients.
 We want to enhance the rate at which messages are handled and sent out.
 Efficient use of bandwidth, CPU, and memory helps keep communication fast and
effective.
2. Challenges in Performance
There are challenges that come with achieving high performance:
 Making sure messages arrive in the right order can be tough, especially with strict
protocols.
 Handling multiple users trying to access shared resources at the same time can lead to
slowdowns.
 Communication needs to adjust based on changing conditions, like slow bandwidth or
lost packets.
3. Strategies for Improvement
To boost performance, consider these strategies:
 Smart Routing: Using efficient routing methods can reduce delays by cutting down on
the number of hops messages take.
 Asynchronous Communication: This allows senders and receivers to work
independently, improving responsiveness.
 Pre-storing Data: Keeping frequently accessed messages or data ready can help
lower delays and speed up responses.
Challenges of Group Communication in Distributed Systems
Group communication in distributed systems comes with several challenges due to the
need to coordinate multiple nodes that may be spread out or connected through unreliable
networks. Key challenges include:
 Reliability: Messages must reach all intended recipients, even during network failures
or node crashes, which can be complicated when nodes frequently join or leave.
 Scalability: As the number of participants grows, managing communication effectively
becomes harder, leading to issues with bandwidth usage and processing delays.
 Concurrency and Consistency: Keeping shared data consistent while allowing
simultaneous updates is tricky, requiring strong synchronization to avoid conflicts.
 Fault Tolerance: The system must handle node failures and communication issues
without losing reliability. This means having mechanisms to detect failures and manage
changes in group membership.
FAQs for Group Communication in Distributed Systems

Locking Mechanism in Concurrency Control

In database management and distributed systems, a locking mechanism is a
technique used to manage access to data by multiple transactions or processes
simultaneously. It ensures data consistency and prevents issues like lost
updates or dirty reads by controlling when and how transactions can access the
same data.

Locks restrict access to a resource (such as a database record or table) until the transaction
that holds the lock completes, ensuring atomicity, consistency, isolation, and
durability (ACID) properties.
 Types of Locks and Their Purposes
1. Shared Lock (S Lock)
 Purpose: Allows multiple transactions to read a resource concurrently but prevents any of
them from writing to it.
 Scenario: If Transaction A holds a shared lock on a record, other transactions can also
obtain shared locks on the same record for reading, but no transaction can modify it until all
shared locks are released.
 Example: Reading a product inventory without modifying it.

2. Exclusive Lock (X Lock)

 Purpose: Grants a transaction exclusive access to a resource, allowing it
to read and write, but blocking all other transactions from accessing the resource (both
read and write).
 Scenario: If Transaction B holds an exclusive lock on a record, no other transaction can
access the record until Transaction B releases the lock.
 Example: Updating a customer's bank balance during a money transfer.

3. Intent Locks
 Purpose: Used in hierarchical locking schemes to indicate a transaction’s intention to lock a
lower-level resource (e.g., a row in a table).
 Types:
 Intent Shared (IS): Indicates intent to acquire shared locks at a finer level.
 Intent Exclusive (IX): Indicates intent to acquire exclusive locks at a finer level.
 Scenario: Before locking a specific row in a table, an intent lock on the table prevents
conflicting actions by other transactions at a higher level.
 4. Read Lock (Compatible with Shared Lock)
 Purpose: A variant of the shared lock, explicitly designed for read operations.
 Scenario: Ensures that multiple transactions can read a resource concurrently but prevents
writing.

5. Write Lock (Compatible with Exclusive Lock)

 Purpose: A variant of the exclusive lock, designed for write operations.
 Scenario: Prevents all other transactions from accessing the resource in any way.

Lock Compatibility Matrix

Requesting Transaction Shared Lock Exclusive Lock

Shared Lock ✅ Allowed ❌ Denied

Exclusive Lock ❌ Denied ❌ Denied

 ✅ Allowed: Indicates compatibility (e.g., multiple shared locks can coexist).

 ❌ Denied: Indicates conflict (e.g., shared and exclusive locks cannot coexist).