An atomic transaction, often referred to simply as an “atomic transaction,” is a concept in computer science and database management that ensures that a series of operations or database changes are treated as a single, indivisible unit of work. The term “atomic” in this context refers to the indivisible nature of the transaction — it either occurs completely, or not at all. In other words, an atomic transaction is all or nothing.
The properties of an atomic transaction are often summarized using the acronym “ACID,” which stands for:
1. Atomicity: This property ensures that either all the changes in a transaction are committed (applied) to the database, or none of them are. If any part of the transaction fails, the entire transaction is rolled back, and the database remains unchanged.
2. Consistency: A transaction brings the database from one consistent state to another consistent state. It means that the data follows predefined integrity rules and constraints before and after the transaction.
3. Isolation: Isolation ensures that multiple transactions can be executed concurrently without interfering with each other. Each transaction is isolated from others until it is completed, preventing changes from one transaction from being visible to others before they are committed.
4. Durability: Once a transaction is committed, its changes become permanent, even in the face of system crashes or failures. The changes are saved in a way that ensures they will survive subsequent system failures.
Atomic transactions are crucial for maintaining data integrity and reliability, especially in systems where multiple users or processes interact with a shared database. They ensure that data remains consistent even in the presence of hardware failures, software crashes, or other unexpected events.
Relational database management systems (RDBMS) and many modern NoSQL databases provide mechanisms to manage atomic transactions. Developers often use programming constructs or database commands to group a series of operations into a transaction scope, ensuring that the ACID properties are upheld.
It’s worth noting that while atomic transactions are a powerful concept, there are situations where relaxing some of the ACID properties might be acceptable for performance or scalability reasons. In such cases, developers might opt for alternative approaches like eventual consistency or distributed transaction coordination.
Atomic Transactions are associated with Database operations where a set of actions must ALL complete or else NONE of them complete. For example, if someone is booking a flight, you want to both get payment AND reserve the seat OR do neither. If either one were allowed to succeed without the other also succeeding, the database would be inconsistent.
Atomic Operations on the other hand are usually associated with low-level programming with regards to multi-processing or multi-threading applications and are similar to Critical Sections. For example, if two threads both access and modify the same variable, each thread goes through the following steps:
- Read the variable from storage into local memory.
- Modify the value in local memory.
- Write the modified value back to the original storage location.
But in a multi-threaded system an interrupt or other context switch might happen after the first process has read the value but has not written it back. The second process (or interrupt) will then read and modify the OLD value and write its modified value back to storage. When the first process is re-enabled, it doesn’t know that something might have changed so it writes back its change to the original value. Hence the operation that the second process did to the variable will be lost. If an operation is atomic, it is guaranteed to complete without being interrupted once it begins. This is usually accomplished using hardware-level primitives like Test-and-Set or Compare-and-Swap.
