Distributed Transactions

Communication between diverse applications is an essential requirement in today's distributed network environments. This communication can be at a single tier where one application communicates to another in a single transaction, or at a multiple tier where many applications communicating to each other in one large transaction. The ability of a transaction to span multiple applications is fundamental to multi-process communication.

The availability of low-cost computing power and increased network bandwidth gives rise to distributed component-based computing applications. Distributed computing applications and distributed transactions are vital for developing computing components for multi-tier applications, which can run on different platforms or through networks. Here, a transaction is defined as a unit of work composed of sets of operations on objects. A distributed component-based application is a configuration of services provided by different application components. These components are executed on physically independent systems running on multiple machines. To the user, these components appear as a single application running on a single physical machine.

Overview

In the world of distributed computing and distributed transactions, a transaction can be defined as a group of statements representing a unit of work composed of a set of operations on objects. These groups of statements must be executed in totality as a unit. Transactions can also be viewed as sequences of operations on resources, such as read, write, or update, which transform one consistent state of the system into a new consistent state. The basis of these transactions lies in the fundamental concept of an all-or-nothing proposition. Either all steps of a transaction must be completed successfully or none of them should be completed.

In a large network, spread over multiple machines and involving many individual steps for a transaction, it is highly probable that one of these steps do not get completed. This can occur due to many reasons such as flawed application logic, server failure, hardware failure, and network interruptions. Due to unpredictable environmental factors, transactions must adhere to the following properties:

Atomicity: This is the all-or-nothing property. Either the entire sequence of operations is successful or unsuccessful. A transaction should be treated as a single unit of operation. Only completed transactions are committed and incomplete transactions are rolled back or restored to their original state.
Consistency: A transaction maps one consistent state of resources (for example, database) to another. Consistency is concerned with correctly reflecting the reality of the state of the resources. Some examples of consistency are the referential integrity of the database and unique primary keys in tables.
Isolation: A transaction should not reveal its results to other concurrent transactions before it commits. Isolation assures that transactions do not access data that is being concurrently updated. The other name for isolation is "serialization".
Durability: Results of completed transactions have to be made permanent and cannot be erased from the database if the system fails. Resource managers ensure that the results of a transaction are not altered due to system failures.

Go through the following sections for more: