Editing Atomic commit (section)

==Database systems==
Atomic commits in database systems fulfil two of the key properties of [[ACID]],<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=620 |publisher=Addison Wesley |year=2006}}</ref> [[Atomicity (database systems)|atomicity]] and  [[Consistency (database systems)|consistency]]. Consistency is only achieved if each change in the atomic commit is consistent.

As shown in the example atomic commits are critical to multistep operations in databases. Due to modern hardware design of the [[Data storage device|physical disk]] on which the database resides true atomic commits cannot exist. The smallest area that can be written to on disk is known as a sector. A single database entry may span several different sectors. Only one sector can be written at a time. This writing limit is why true atomic commits are not possible. After the database entries in [[Computer memory|memory]] have been modified they are queued up to be written to disk. This means the same problems identified in the example have reoccurred. Any algorithmic solution to this problem will still encounter the Two Generals’ Problem. The [[two-phase commit protocol]] and [[three-phase commit protocol]] attempt to solve this and some of the other problems associated with atomic commits.

The two-phase commit protocol requires a coordinator to maintain all the information needed to recover the original state of the database if something goes wrong. As the name indicates there are two phases, <u>voting</u> and <u>commit</u>.

During the <u>voting</u> phase each node writes the changes in the atomic commit to its own disk. The nodes then report their status to the coordinator. If any node does not report to the coordinator or their status message is lost the coordinator assumes the node's write failed. Once all of the nodes have reported to the coordinator the second phase begins.

During the <u>commit</u> phase the coordinator sends a commit message to each of the nodes to record in their individual logs. Until this message is added to a node's log, any changes made will be recorded as incomplete. If any of the nodes reported a failure the coordinator will instead send a rollback message. This will remove any changes the nodes have written to disk.<ref>{{cite book |last=Elmasri |first=Ramez |title=Fundamentals of Database Systems 5th Edition |page=688 |publisher=Addison Wesley |year=2006}}</ref><ref>{{cite book |first1=Philip A. |last1=Bernstein |first2=Vassos |last2=Hadzilacos |first3=Nathan |last3=Goodman |title=Concurrency Control and Recovery in Database Systems |chapter=Chapter 7 |publisher=Addison Wesley Publishing Company |year=1987 |url=http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx}}</ref>

The three-phase commit protocol seeks to remove the main problem with the two phase commit protocol, which occurs if a coordinator and another node fail at the same time during the commit phase neither can tell what action should occur. To solve this problem a third phase is added to the protocol. The <u>prepare to commit</u> phase occurs after the <u>voting</u> phase and before the <u>commit</u> phase.

In the <u>voting</u> phase, similar to the two-phase commit, the coordinator requests that each node is ready to commit. If any node fails the coordinator will timeout while waiting for the failed node. If this happens the coordinator sends an abort message to every node. The same action will be undertaken if any of the nodes return a failure message.

Upon receiving success messages from each node in the voting phase the <u>prepare to commit</u> phase begins. During this phase the coordinator sends a prepare message to each node. Each node must acknowledge the prepare message and reply. If any reply is missed or any node return that they are not prepared then the coordinator sends an abort message. Any node that does not receive a prepare message before the timeout expires aborts the commit.

After all nodes have replied to the prepare message then the <u>commit</u> phase begins. In this phase the coordinator sends a
commit message to each node. When each node receives this message it performs the actual commit. If the commit message does not reach a node due to the message being lost or the coordinator fails they will perform the commit if the timeout expires. If the coordinator fails upon recovery it will send a commit message to each node.<ref>{{cite book |first=Srinivas R. |last=Gaddam |title=Three-Phase Commit Protocol |url=http://ei.cs.vt.edu/~cs5204/fall99/distributedDBMS/sreenu/3pc.html}}</ref>