Content deleted Content added
grammar |
|||
Line 22:
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.
Line 34:
The other area where atomic commits are employed is [[revision control]] systems. This allows multiple modified files to be uploaded and merged into the source. Most revision control systems support atomic commits ([[Concurrent Versions System|CVS]], [[Microsoft Visual SourceSafe|VSS]] and [[IBM Rational ClearCase]] (when in [[IBM Rational ClearCase UCM|UCM]] mode)<ref>http://pic.dhe.ibm.com/infocenter/cchelp/v8r0m0/topic/com.ibm.rational.clearcase.ccrc.help.doc/topics/u_checkin.htm?resultof=%22%61%74%6f%6d%69%63%22%20%22%61%74%6f%6d%22%20%22%63%6f%6d%6d%69%74%22%20</ref> are the major exceptions).
Like database systems, commits may fail due to a problem in applying the changes on disk. Unlike a database system, which overwrites any existing data with the data from the [[changeset]], revision control systems [[merge (revision control)|merge]] the modification in the changeset into the existing data. If the system cannot complete the merge then the commit will be rejected. If a merge cannot be resolved by the revision control software it is up to the user to merge the changes. For revision control systems that support atomic commits, this failure in merging would result in a failed commit.
Atomic commits are crucial for maintaining a consistent state in the repository. Without atomic commits some changes a developer has made may be applied but other changes may not. If these changes have any kind of coupling this will result in errors. Atomic commits prevent this by not applying partial changes
==Atomic Commit Convention==
| |||