Distributed Transaction Model

A distributed transaction is often a flat transaction that operates in a distributed environment and
so must visit multiple nodes in the network depending on where the data is hosted. It is a set of
data operations that are carried out across two or more data repositories (especially databases).
It is usually coordinated among numerous nodes linked by a network, but it can also span
multiple databases on a single server. There are two conceivable outcomes: a) all operations
complete successfully, or b) no operations are conducted at all due to a breakdown elsewhere in
the system. If any work was accomplished previous to the failure, it will be reversed to ensure no
net work was done. This type of operation adheres to the database's "ACID" (atomicity-
consistency-isolation-durability) principles, which maintain data integrity.

Distributed transactions have the same processing needs as conventional database transactions,
but they must be maintained across different resources, which makes them more difficult for
database developers to implement. Multiple resources introduce additional failure points, such as
the independent software systems that execute the resources (e.g., the database software), the
additional hardware servers, and network issues. This makes distributed transactions prone to
failure, which is why controls for data integrity must be implemented.

Distributed transaction processing

1
The coordinator process begins the execution of the distributed transaction; each process is
located at the site with the components like transaction manager (TM), scheduler (SC), and
recovery manager (RM). The TM handles the replica control protocol and the distributed
transaction execution. The SC handles the distributed concurrency control protocol while the RM
handles the local recovery protocol.

To ensure the success of a distributed transaction, transaction managers (TM) coordinate the
resources (either multiple databases or multiple nodes of a single database). The transaction
manager can be one of the data repositories updated as part of the transaction, or it might be a
completely different resource that is exclusively responsible for coordination. The transaction
manager determines whether to commit a successful transaction or rollback an unsuccessful
one, leaving the database unchanged..

A distributed transaction is requested by an application to the transaction manager. The

The two-phase commit algorithm is a widely used technique for ensuring the accurate
completion of a distributed transaction (atomicity). This technique is typically used for updates
that can be committed quickly.

Phase 1 (voting phase):

1. The coordinator sends a canCommit? request to each of the participants in the transaction.

2
2. When a participant receives a canCommit? request it replies with its vote (Yesor No) to the
coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If
the vote is No the participant aborts immediately.

Phase 2 (completion according to outcome of vote):

3. The coordinator collects the votes (including its own).

(a) If there are no failures and all the votes are Yes the coordinator decides to commit the
transaction and sends a doCommit request to each of the participants.

(b) Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all
participants that voted Yes.

4. Participants that voted Yes are waiting for a doCommitor doAbort request from the
coordinator. When a participant receives one of these messages it acts accordingly and in the
case of commit, makes a haveCommitted call as confirmation to the coordinator.

Why are distributed transactions needed?

Distributed transactions are required when related data is dispersed across different databases
and needs to be updated fast. For instance, if you have various systems that maintain customer
information and you need to make a global update (such as changing the postal address) across
all records, a distributed transaction ensures that all records are updated. And in the event of a
failure, the data is restored to its original condition, and the originating application is responsible
for submitting the transaction.

The conceptual difference between a distributed transaction and a nested transaction can be put
as follows:
The structure of nested transactions is governed by the application's functional decomposition,
or by what the program perceives as spheres of control. The structure of a distributed
transaction is determined by how data is dispersed through a network. In other words, even if a
flat transaction is used, the application may require a distributed transaction to be conducted if
the data is spread across multiple nodes.

3
 Graphical representation of distributed transaction model

Assume that transaction T is running on node A and that it involves the joining of two tables, X
and Y. Because only X is available locally, Y must be obtained via the network. This results in
the spawning of T subtransactions T1 and T2 at the two other nodes, B and C, each of which
holds a partition of Y.

The decomposition into subtransactions does not reflect a hierarchical structure in the programs
to be executed, but is induced by the placement of data in the network. Consequently, the
subtractions are not really executing at a lower level of control, as is the case in the nested
transactions. Rather they are “slices” of the same top-level transaction. In other words: simple
flat transactions (from the application's perspective) may be executed as distributed transactions
if they run in a distributed database system and the data they access are scattered across
multiple nodes. If a subtransaction issues COMMIT WORK, this signals the commit of the

4
entire transaction, which forces all other subtransactions to commit. By comparison, in a nested
transaction, this is simply a local commit of that subtransaction, the final success of which
depends on the commit of the ancestors in the tree. Distributed subtransactions normally cannot
rollback independently as their decision to abort also affects the entire transaction. This
means that the coupling between subtransactions and their parents is much stronger than in the
distributed model
Here is another example:

The TID (T) is passed with each request e.g. withdraw(T,3). A client’s (flat) banking transaction
involves accounts A, B, Cand D at servers BranchX, BranchYand BranchZ. Each server is
shown with a participant, which joins the transaction by invoking the join method in the
coordinator. The coordinator has openTransaction, closeTransaction and abortTransaction.
openTransaction returns a TID which is passed with each operation so that servers know which
transaction is accessing its objects. The Coordinator interface provides an additional method,
join,which is used whenever a new participant joins the transaction:
–join(Trans, reference to participant) - informs a coordinator that a new participant has joined the
transaction
Trans– the coordinator records the new participant in its participant list. The fact that the
coordinator knows all the participants and each participant knows the coordinator will enable
them to collect the information that will be needed at commit time.