Distributed Transaction Processing

What is the need for a Distributed Transaction?

The need for distributed transactions arises from the requirements to ensure data consistency and reliability
across multiple independent systems or resources in a distributed computing environment. Specifically:

● Consistency: Ensuring that all changes made as part of a transaction are committed or rolled back
atomically, maintaining data integrity.
● Isolation: Guaranteeing that concurrent transactions do not interfere with each other, preserving data
integrity and preventing conflicts.
● Durability: Confirming that committed transactions persist even in the event of system failures,
ensuring reliability.
● Atomicity: Ensuring that either all operations within a transaction are completed successfully or none
of them are, avoiding partial updates that could lead to inconsistencies.
Working of Distributed Transactions

The working of Distributed Transactions is the same as that of simple transactions but the challenge is to
implement them upon multiple databases. Due to the use of multiple nodes or database systems, there
arises certain problems such as network failure, to maintain the availability of extra hardware servers and
database servers. For a successful distributed transaction the available resources are coordinated by
transaction managers.
Step 1: Application to Resource - Issues Distributed Transaction

The first step is to issue that distributed transaction. The application initiates the transaction by
sending the request to the available resources. The request consists of details such as operations
that are to be performed by each resource in the given transaction.

Step 2: Resource 1 to Resource 2 - Ask Resource 2 to Prepare to Commit

Once the resource receives the transaction request, resource 1 contacts resource 2 and asks resource
2 to prepare the commit. This step makes sure that both the available resources are able to perform
the dedicated tasks and successfully complete the given transaction.

Step 3: Resource 2 to Resource 1 - Resource 2 Acknowledges Preparation

After the second step, Resource 2 receives the request from Resource 1, it prepares for the commit.
Resource 2 makes a response to resource 1 with an acknowledgment and confirms that it is ready to
go ahead with the allocated transaction.
Step 4: Resource 1 to Resource 2 - Ask Resource 2 to Commit

Once Resource 1 receives an acknowledgment from Resource 2, it sends a request to Resource 2 and provides
an instruction to commit the transaction. This step makes sure that Resource 1 has completed its task in the
given transaction and now it is ready for Resource 2 to finalize the operation.

Step 5: Resource 2 to Resource 1 - Resource 2 Acknowledges Commit

When Resource 2 receives the commit request from Resource 1, it provides Resource 1 with a response and
makes an acknowledgment that it has successfully committed the transaction it was assigned to. This step
ensures that Resource 2 has completed its task from the operation and makes sure that both the resources
have synchronized their states.

Step 6: Resource 1 to Application - Receives Transaction Acknowledgement

Once Resource 1 receives an acknowledgment from Resource 2, Resource 1 then sends an acknowledgment of
the transaction back to the application. This acknowledgment confirms that the transaction that was carried
out among multiple resources has been completed successfully.
Types of Distributed Transactions

Distributed transactions involve coordinating actions across multiple nodes or resources to ensure
atomicity, consistency, isolation, and durability (ACID properties). Here are some common types and
protocols:

1. Two-Phase Commit Protocol (2PC)

This is a classic protocol used to achieve atomicity in distributed transactions.

● It involves two phases: a prepare phase where all participants agree to commit or abort the
transaction, and a commit phase where the decision is executed synchronously across all
participants.
● 2PC ensures that either all involved resources commit the transaction or none do, thereby
2. Three-Phase Commit Protocol (3PC)

3PC extends 2PC by adding an extra phase (pre-commit phase) to address certain failure scenarios that
could lead to indefinite blocking in 2PC.
● In 3PC, participants first agree to prepare to commit, then to commit, and finally to complete or
abort the transaction.
● This protocol aims to reduce the risk of blocking seen in 2PC by introducing an additional
decision-making phase.
3. XA Transactions

XA (eXtended Architecture) Transactions are a standard defined by The Open Group for
coordinating transactions across heterogeneous resources (e.g., databases, message queues).
● XA specifies interfaces between a global transaction manager (TM) and resource
managers (RMs).
● The TM coordinates the transaction's lifecycle, ensuring that all participating RMs
either commit or rollback the transaction atomically.
Implementing Distributed Transactions

Below is how distributed transactions is implemented:

● Transaction Managers (TM):
○ Transaction Managers are responsible for coordinating and managing
transactions across multiple resource managers (e.g., databases, message
queues).
○ TMs ensure that transactions adhere to ACID properties (Atomicity,
Consistency, Isolation, Durability) even when involving disparate resources.
● Resource Managers (RM):
○ Resource Managers are responsible for managing individual resources (e.g.,
databases, file systems) involved in a distributed transaction.
○ RMs interact with the TM to prepare for committing or rolling back transactions
based on the TM's coordination.
● Coordination Protocols:
○ Implementations of distributed transactions often rely on coordination protocols
like 2PC, 3PC, or variants such as Paxos and Raft for consensus.
○ These protocols ensure that all participants in a transaction reach a consistent
decision regarding commit or rollback.
Advantages of Distributed Transactions

● Data Consistency: Data Consistency is being provided across multiple resources by distributed
transactions. Various Operations are being coordinated across multiple database resources. This
makes sure that system remains in a consistent state even in case of any type of failure.
● Fault Tolerance: Distributed systems can handle faults and ensure proper transactions. If the
participating resource fails during the execution of the transaction the transaction can be then rolled
back on alternate resources and completed successfully.
● Guarantees Transactions: Distributed systems guarantee the transaction. It provides features such as
durability and isolation. The durability makes sure that if any transaction is committed, the changes
last even if any failures occur.
Disadvantages of distributed transactions

Complexity: Coordinating transactions across multiple databases/resources is difficult to implement

and maintain. Protocols like two-phase commit add extra overhead.

Performance Overhead: Since transactions involve network communication, locking, and

synchronization, they are slower than local transactions.

Network Dependency: Distributed transactions rely on stable networks. Any delay, partition, or
failure in the network can disrupt or slow the transaction.
Applications Distributed Transactions

● Enterprise Resource Planning (ERP) Systems: ERP systems consist of departments within one
organization. Therefore distributed transactions are used here in order to maintain transactions from
various modules such as sales, inventory, finance, and human resources management.
● Cloud Computing: Distributed transactions are being used in cloud-based applications. Transactions
can be done with the help of multiple data sources and ensure that data updates and operations that
are performed consistently.
● Healthcare Systems: Healthcare systems make use of Distributed transactions when coordinating
patient records, scheduling appointments for patients, and managing the billing systems. Distributed
transactions maintain data consistency and performance in healthcare systems.
Thank You