Atomic commit: Difference between revisions

Revision as of 13:36, 3 July 2019

Revision as of 16:39, 16 November 2019

Line 18:

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’snode'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>

Line 34:

Atomic commits are a common feature of [[revision control|version control software]], and crucial for maintaining a consistent state in the repository.<ref name="levenberg">{{cite web |last1=Levenberg |first1=Rachel Potvin, Josh |title=Why Google Stores Billions of Lines of Code in a Single Repository|url=https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext |website=Communications of the ACM |accessdate=20 July 2018|date=July 2016}}</ref> Most version control software will not apply any part of a commit that fails. Notable exceptions are [[Concurrent Versions System|CVS]], [[Microsoft Visual SourceSafe|VSS]] and [[IBM Rational ClearCase]] (when in UCM mode).<ref>{{cite book |last1=Smart |first1=John Ferguson |title=Java Power Tools |date=2008 |publisher="O'Reilly Media, Inc." |isbn=9781491954546 |page=301 |url=https://books.google.com/books?id=kE0UDQAAQBAJ&pg=PA301&dq=visual+sourcesafe+atomic+commit&hl=en&sa=X&ved=0ahUKEwjnmpjB8L3cAhUJON8KHeuXBt0Q6AEIKTAA#v=onepage&q=visual%20sourcesafe%20atomic%20commit&f=false |accessdate=26 July 2018 |language=en}}</ref>

For instance, if version control software encounters a [[Edit_conflictEdit conflict|merge conflict]] that can not be automatically resolved, then no part of the changeset is merged. Instead, the developer is given an opportunity to either revert their changes or manually resolve the conflict.

This prevents the entire project from entering a broken state due to a partially applied change set, where one file from a commit is successfully committed, but another file with dependent changes fails.<ref name="versperman">{{cite book |last1=Vesperman |first1=Jennifer |title=Essential CVS. |date=2009 |publisher=O'Reilly Media, Inc. |___location=Sebastopol |isbn=9780596551407 |page=7 |edition=2nd |url=https://books.google.com/books?id=nIMNLXCBjn0C&pg=PA7&lpg=PA7&dq=atomic+commit+cvs&source=bl&ots=UsXJlcVjGI&sig=4NgDmiKx8yQx-wxCyKls89Clpiw&hl=en&sa=X&ved=2ahUKEwi7yNKe773cAhWCpoMKHUpsA-44ChDoATACegQIAhAB#v=onepage&q=atomic%20commit%20cvs&f=false|quote=A feature that CVS doesn't have, and that many teams like, is atomic commits. This feature ensures that while one person is committing changes to the repository, no one else can. Thus, each commit is a separate process, and the repository is never in a state where it has mismatched files.}}</ref>