Skip to main content

ACID Properties

ACID is a concept (and an acronym) that refers to the four properties of a transaction in a database system, which are: Atomicity, Consistency, Isolation and Durability.

Atomicity​

The phrase "all or nothing" succinctly describes the first ACID property of atomicity. When an update occurs to a database, either all or none of the update becomes available to anyone beyond the user or application performing the update.

This update to the database is called a transaction and it either commits or aborts. This means that only a fragment of the update cannot be placed into the database, should a problem occur with either the hardware or the software involved.

Features to consider for atomicity

  • The transaction is a unit of operation - either all the transaction's actions are completed or none
  • atomicity is maintained in the presence of deadlocks, database software failures, application software failures, CPU failures and disk failures
  • atomicity can be turned off at the system level and session level

Consistency​

Consistency is the ACID property that ensures that any changes to values in an instance are consistent with changes to other values in the same instance. A consistency constraint is a predicate on data which serves as a precondition, post-condition, and transformation condition on any transaction.

Isolation​

The isolation is needed when there are concurrent transactions. Concurrent transactions are transactions that occur at the same time, such as shared multiple users accessing shared objects.

As an example, if two people are updating the same catalog item, it's not acceptable for one person's changes to be "clobbered" when the second person saves a different set of changes. Both users should be able to work in isolation, working as though he or she is the only user. Each set of changes must be isolated from those of the other users.

Degrees of isolation:

  • degree 0 - a transaction does not overwrite data updated by another user or process ("dirty data") of other transactions
  • degree 1 - degree 0 plus a transaction does not commit any writes until it completes all its writes (until the end of transaction)
  • degree 2 - degree 1 plus a transaction does not read dirty data from other transactions
  • degree 3 - degree 2 plus other transactions do not dirty data read by a transaction before the transaction commits

Durability​

Maintaining updates of committed transactions is critical. These updates must never be lost. The durability addresses this need. Durability refers to the ability of the system to recover committed transaction updates if either the system or the storage media fails.

Features to consider for durability

  • recovery to the most recent successful commit after a database software failure or an application software failure or CPU failure or data disk failure
  • recovery to the most recent successful backup after a disk failure