Editing ACID (section)

== Implementation ==
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. There are two popular families of techniques: [[write-ahead logging]] and [[shadow paging]]. In both cases, [[Lock (computer science)|lock]]s 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. In write ahead logging, durability is guaranteed by writing the prospective change to a persistent log before changing the database. That allows the database to return to a consistent state in the event of a crash. In shadowing, updates are applied to a partial copy of the database, and the new copy is activated when the transaction commits.

=== Locking vs. multiversioning ===
Many databases rely upon locking to provide ACID capabilities. Locking means that the transaction marks the data that it accesses so that the DBMS knows not to allow other transactions to modify it until the first transaction succeeds or fails. The lock must always be acquired before processing data, including data that is read but not modified. Non-trivial transactions typically require a large number of locks, resulting in substantial overhead as well as blocking other transactions. For example, if user A is running a transaction that has to read a row of data that user B wants to modify, user B must wait until user A's transaction completes. [[Two-phase locking]] is often applied to guarantee full isolation.

An alternative to locking is [[multiversion concurrency control]], in which the database provides each reading transaction the prior, unmodified version of data that is being modified by another active transaction. This allows readers to operate without acquiring locks, i.e., writing transactions do not block reading transactions, and readers do not block writers. Going back to the example, when user A's transaction requests data that user B is modifying, the database provides A with the version of that data that existed when user B started his transaction. User A gets a consistent view of the database even if other users are changing data. One implementation, namely [[snapshot isolation]], relaxes the isolation property.

=== Distributed transactions ===
{{Main article|Distributed transaction}}
Guaranteeing ACID properties in a [[distributed transaction]] across a [[distributed database]], where no single node is responsible for all data affecting a transaction, presents additional complications. Network connections might fail, or one node might successfully complete its part of the transaction and then be required to roll back its changes because of a failure on another node. The [[two-phase commit protocol]] (not to be confused with [[two-phase locking]]) provides atomicity for [[distributed transaction]]s to ensure that each participant in the transaction agrees on whether the transaction should be committed or not.<ref name=Bern2009>{{cite book |author-link1=Phil Bernstein |first1=Philip A. |last1=Bernstein |first2=Eric |last2=Newcomer |date=2009 |url=http://www.elsevierdirect.com/product.jsp?isbn=9781558606234 |title=Principles of Transaction Processing |edition=2nd |archive-url=https://web.archive.org/web/20100807151625/http://www.elsevierdirect.com/product.jsp?isbn=9781558606234 |archive-date=2010-08-07 |chapter=Chapter 8 |publisher=Morgan Kaufmann (Elsevier) |isbn=978-1-55860-623-4}}</ref> Briefly, in the first phase, one node (the coordinator) interrogates the other nodes (the participants), and only when all reply that they are prepared does the coordinator, in the second phase, formalize the transaction.