ACID

In databases, ACID stands for Atomicity, Consistency, Isolation, and Durability. They are considered to be the key transaction processing features of a database management system, or DBMS. Without them, the integrity of the database cannot be guaranteed.

In the context of databases, a single logical operation on the data is called a transaction. A transfer of funds from one account to another is considered a transaction, for example, even though it might consist of multiple tasks (debiting one account and crediting another). The ACID properties guarantee that such transactions are processed reliably.

• Atomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are. The transfer of funds can be completed or it can fail for a multitude of reasons, but atomicity guarantees that one account won't be debited if the other is not credited as well.

• Consistency refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction can't break the rules, or integrity constraints, of the database. If an integrity constraint states that all accounts must have a positive balance, then any transaction violating this rule will be aborted.

• Isolation[?] refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; a bank manager can see the transferred funds on one account or the other, but never on both -- even if he ran his query while the transfer was still being processed. More formally, isolation means the transaction history[?] is serializable[?].

• Durability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. This means it will survive system failure, and that the database system has checked the integrity constraints and won't need to abort the transaction. Typically, all transactions are written into a log that can be played back to recreate the system to the its state right before the failure. A transaction can only be deemed committed after it is safely in the log.

Implementing the ACID properties correctly is not simple. Processing a transaction often requires a number of small changes to be made, including updating indexes that are used by the system to speed up searches. This sequence of operations is subject to failure for a number of reasons; for instance, the system may have no room left on its disk drives.

ACID suggests that the database be able to perform all of these operations at once. In fact this is difficult to arrange. There are two popular families of techniques: Write ahead logging and Shadow paging. In both cases, locks must be acquired on all information that is read and updated. In write ahead logging, atomicity is guaranteed by ensuring that all REDO and UNDO information is written to a log before it is written to the database. In shadowing, updates are applied to a copy of the database, and the new copy is activated when the transaction commits. The copy refers to unchanged parts of the old version of the database, rather than being an entire duplicate.

In distributed transactions[?], two-phase commit[?] is typically applied to ensure that each participant on the transaction agree on whether the transaction should be committed or not.

Care must be taken when running transactions in parallel. Two phase locking is typically applied to guarantee full isolation[?].

The ACID concept is described in ISO/IEC 10026-1:1992 Section 4.