Content deleted Content added
Citation bot (talk | contribs) Alter: url. URLs might have been internationalized/anonymized. | You can use this bot yourself. Report bugs here. | Suggested by AManWithNoPlan | All pages linked from cached copy of User:AManWithNoPlan/sandbox2 | via #UCB_webform_linked 936/13166 |
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
||
| (10 intermediate revisions by 8 users not shown) | |||
Line 1:
{{Short description|Operation that applies a set of distinct changes as a single operation}}
In the field of [[computer science]], an '''atomic [[Commit (data management)|commit]]''' is an operation that applies a set of distinct changes 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 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=[https://archive.org/details/databasesystemsc0000_2ndedgarc/page/1008 1008]–1009 |publisher=Prentice Hall |year=2009|isbn=9780131873254 }}</ref>
==Usage==
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, the wrong balance for Y will be reported.
Line 41:
==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 one is 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. One need not look through 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.
| |||