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 1983,[1] Andreas Reuter and Theo Härder coined the acronym ACID, building on earlier work by Jim Gray[2] 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).
[3] The characteristics of these four properties as defined by Reuter and Härder are as follows: Transactions are often composed of multiple statements.
[4] A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright.
An example of a database invariant is referential integrity, which guarantees the primary key–foreign key relationship.
A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright.
The entire transaction must be canceled and the affected rows rolled back to their pre-transaction state.
If there had been other constraints, triggers, or cascades, every single change operation would have been checked in the same way as above before the transaction was committed.
To demonstrate isolation, we assume two transactions execute at the same time, each attempting to modify the same data.
Consider two transactions: Combined, there are four actions: If these operations are performed in order, isolation is maintained, although T2 must wait.
By interleaving the transactions, the actual order of actions might be: Again, consider what happens if T1 fails while modifying B in Step 4.
Processing a transaction often requires a sequence of operations that is subject to failure for a number of reasons.
For instance, the system may have no room left on its disk drives, or it may have used up its allocated CPU time.
In both cases, locks must be acquired on all information to be updated, and depending on the level of isolation, possibly on all data that may be read as well.