Atomic commit: Difference between revisions

Revision as of 01:02, 7 August 2014

Latest revision as of 10:27, 15 September 2023

(32 intermediate revisions by 27 users not shown)

Line 1:

{{Short description|Operation that applies a set of distinct changes as a single operation}}

{{Cleanup|date=July 2010}}

AnIn the field of [[computer science]], an '''atomic [[Commit (data management)|commit]]''' is an operation inthat whichapplies a set of distinct changes is applied as a single operation. If the changes are applied, then the atomic commit is said to have succeeded. If there is a failure before the atomic commit can be completed, then all of the changes completed in the atomic commit are reversed. This ensures that the system is always left in a consistent state. The other key property of isolation comes from their nature as [[atomicity (database systems)|atomic]] operations. Isolation ensures that only one atomic commit is processed at a time. The most common uses of atomic commits are in [[database systems]] and [[RevisionVersion control|revisionversion control systems]].

The problem with atomic commits is that they require coordination between multiple systems.<ref>{{cite book |last=Bocchi |first=Wischik |title=A Process Calculus of Atomic Commit |year=2004}}</ref> As computer networks are unreliable services, this means no algorithm can coordinate with all systems as proven in the [[Two Generals' Problem|Two Generals Problem]]. As databases become more and more distributed, this coordination will increase the difficulty of making truly atomic commits.<ref>{{cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=Database Systems The Complete Book |url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |pages=1008–1009[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/1008 1008]–1009 |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>

==Usage==

==Necessity for Atomic Commits==

Atomic commits are essential for multi-step updates to data. This can be clearly shown in a simple example of a money transfer between two checking accounts.<ref>{{Cite book |first1=Hector |last1=Garcia-Molina |first2=Jeff |last2=Ullman |first3=Jennifer |last3=Widom |title=Database Systems The Complete Book |url=https://archive.org/details/databasesystemsc0000_2ndedgarc |url-access=registration |page=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/299 299] |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>

This example is complicated by a transaction to check the balance of account Y during a transaction for transferring 100 dollars from account X to Y. To start, first 100 dollars is removed from account X. Second, 100 dollars is added to account Y. If the entire operation is not completed as one atomic commit, then several problems could occur. If the system fails in the middle of the operation, after removing the money from X and before adding into Y, then 100 dollars has just disappeared. Another issue is if the balance of Y is checked before the 100 dollars is added., Thethe wrong balance for Y will be reported.

With atomic commits neither of these cases can happen, in the first case of the system failure, the atomic commit would be rolled back and the money returned to X. In the second case, the request of the balance of Y cannot occur until the atomic commit is fully completed.

==Database Systemsystems==

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.

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>

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 31:

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>

==Revision Controlcontrol==

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&q=visual+sourcesafe+atomic+commit&pg=PA301 |accessdate=26 July 2018 |language=en}}</ref>

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).

For instance, if version control software encounters a [[Edit 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.

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.

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&q=atomic+commit+cvs&pg=PA7|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>

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 which would create these errors. Note that if the changes already contain errors, atomic commits offer no fix.

Atomic commits may also refer to the ability to simultaneously make changes across multiple projects using version control software in a single operation, using a version control software development strategy known as a [[monorepo]].<ref name="levenberg" />

==Atomic Commitcommit Conventionconvention==

==Atomic Commit Convention==

When using a revision control systems a common convention is to use small commits. These are sometimes referred to as atomic commits as they (ideally) only affect a single aspect of the system. These atomic commits allow for greater understandability, less effort to roll back changes, easier bug identification.<ref>{{cite web |publisher=Apache |title=Subversion Best Practices |url=http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html}}</ref>

The greater understandability comes from the small size and focused nature of the commit. It is much easier to understand what is changed and reasoning behind the changes if youone areis only looking for one kind of change. This becomes especially important when making format changes to the source code. If format and functional changes are combined it becomes very difficult to identify useful changes. Imagine if the spacing in a file is changed from using tabs to three spaces every tab in the file will show as having been changed. This becomes critical if some functional changes are also made as a reviewer may simply not see the functional changes.<ref>{{cite book |first=Boisvert |last=Barney |title=Atomic Commits to Version Control |url=http://www.barneyb.com/barneyblog/2006/01/27/atomic-commits-to-version-control/}}</ref><ref>{{cite web |publisher=Conifer Systems |title=The Benefits of Small Commits |url=http://www.conifersystems.com/2008/11/05/the-benefits-of-small-commits/ |access-date=2010-07-28 |archive-date=2011-10-05 |archive-url=https://web.archive.org/web/20111005024703/http://www.conifersystems.com/2008/11/05/the-benefits-of-small-commits/ |url-status=dead }}</ref>

If only atomic commits are made then commits that introduce errors become much simpler to identify. YouOne areneed not required to look thoughthrough every commit to see if it was the cause of the error, only the commits dealing with that functionality need to be examined. If the error is to be rolled back, atomic commits again make the job much simpler. Instead of having to [[Reversion (software development)|revert]] to the offending revision and remove the changes manually before integrating any later changes; the developer can simply revert any changes in the identified commit. This also reduces the risk of a developer accidentally removing unrelated changes that happened to be in the same commit.

Atomic commits also allow bug fixes to be easily reviewed if only a single bug fixesfix is committed at a time. Instead of having to check multiple potentially unrelated files the reviewer must only check files and changes that directly impact the bug being fixed. This also means that bug fixes can be easily packaged for testing as only the changes that fix the bug are in the commit.

==See also==

Line 57 ⟶ 60:

[[Category:Transaction processing]]

[[Category:RevisionVersion control systems]]

[[Category:Distributed computing problems]]