Introduction
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 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.