Editing Durability (database systems) (section)

===Distributed databases===
In [[distributed transaction]]s, ensuring durability requires additional mechanisms to preserve a consistent state sequence across all database nodes. This means, for example, that a single node may not be enough to decide to conclude a transaction by committing it. In fact, the resources used in that transaction may be on other nodes, where other transactions are occurring concurrently. Otherwise, in case of failure, if consistency could not be guaranteed, it would be impossible to acknowledge a safe state of the database for recovery.  For this reason, all participating nodes must coordinate before a commit can be acknowledged. This is usually done by a [[two-phase commit protocol]].<ref name=":4">{{Cite journal |last1=Mohan |first1=C. |last2=Haderle |first2=Don |last3=Lindsay |first3=Bruce |last4=Pirahesh |first4=Hamid |last5=Schwarz |first5=Peter |date=1992-03-01 |title=ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging |journal=ACM Transactions on Database Systems |volume=17 |issue=1 |pages=94–162 |doi=10.1145/128765.128770 |s2cid=8759704 |issn=0362-5915|doi-access=free }}</ref>

In addition, in [[Distributed database|distributed databases]], even the protocols for logging and recovery shall address the issues of [[Distributed computing|distributed environments]], such as [[deadlock (computer science)|deadlock]]s, that could prevent the resilience and recoverability of transactions and, thus, durability.<ref name=":4" /> A widely adopted family of algorithms that ensures these properties is [[Algorithms for Recovery and Isolation Exploiting Semantics|Algorithms for Recovery and Isolation Exploiting Semantics (ARIES)]].<ref name=":3" />