ACID
Relational databases provide the atomicity, consistency, isolation, and durability of ACID [1] properties to maintain the integrity of the database. ACID is a powerful abstraction that simplifies complex interactions with the data and hides many anomalies (like dirty reads, dirty writes, read skew, lost updates, write skew, and phantom reads) behind a simple transaction abort.
In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. In the context of databases, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a transaction. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.
In 1983, Andreas Reuter and Theo Härder coined the acronym ACID, building on earlier work by Jim Gray who named atomicity, consistency, and durability, but not isolation, when characterizing the transaction concept. These four properties are the major guarantees of the transaction paradigm, which has influenced many aspects of development in database systems.
According to Gray and Reuter, the IBM Information Management System supported ACID transactions as early as 1973 (although the acronym was created later).
Transaction
- A transaction is a collection of queries.
- Lifespan: BEGIN -> COMMIT -> ROLLBACK
Let’s discuss ACID in detail.
Atomicity
- A transaction is considered an atomic unit.
- Therefore, all the statements within a transaction will be successfully executed, or none will be executed.
- If a statement fails within a transaction, it should be aborted and rolled back.
- This maintains consistency.
Consistency
- The database should always be consistent and remain consistent after every transaction.
- For example, if multiple users want to view a record from the database, it should return a similar result each time.
Isolation
- Multiple concurrent transactions shouldn’t affect each other.
- The final state of the database should be the same as if the transactions were executed sequentially.
Durability
- The system should guarantee that completed transactions will survive permanently in the database, even in system failure events.
