ACID properties

From Citizendium, the Citizens' Compendium
Jump to: navigation, search
This article is developing and not approved.
Main Article
Talk
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and not meant to be cited; by editing it you can help to improve it towards a future approved, citable version. These unapproved articles are subject to a disclaimer.

In computing, the ACID properties are a set of characteristics that, when enforced, will keep tables, files and databases free from corruption, either when there is a failure or when multiple users try to access the same record at the same time, to perform a transaction. Transactions are application-specific units of work, such as making several interdependent reservations for a multi-segment airline flight, a hotel, and a rental car. While the properties themselves are straightforward, implementing them can be decidedly complex, especially when dealing with distributed databases with multiple copies of the same information.

The basic properties, stated somewhat informally, require that any action that can change the information is:[1]

  • Atomic: Either every action of the transaction takes place, or, if any cannot complete, the information remains exactly the same as it was before the transaction was attempted.
  • Consistent: The transaction performs correctly, within the rules of the application.
  • Isolated: Every transaction runs as if there were no other instances of related transactions being attempted at the same time. In practice, this usually means that there must be a mechanism to lock the information to a transaction while changes take place.
  • Durable: Once a transaction does complete, its effects are permanent and survive failures.
There are a number of special cases, some of which simplify the requirements. For example, idempotent transactions include both read-only functions, and transactions that would update with exactly the same information, so more than one update will not corrupt the data. It is wise to remember, however, that what may seem idempotent may not be so, on a detailed level. For example, while a transaction might be read-only as far as the main data base, it might not be in terms of security logging of accesses to the system as a whole; the data base would not be affected but the log could become inconsistent.
  1. "Scale Up with TP Monitors", Byte Magazine, April 1995