Atomic commit

[1] As computer networks are unreliable services, this means no algorithm can coordinate with all systems as proven in the Two Generals Problem.

As databases become more and more distributed, this coordination will increase the difficulty of making truly atomic commits.

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.

In the second case, the request of the balance of Y cannot occur until the atomic commit is fully completed.

Due to modern hardware design of the physical disk on which the database resides true atomic commits cannot exist.

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.

During the voting phase each node writes the changes in the atomic commit to its own disk.

If any reply is missed or any node return that they are not prepared then the coordinator sends an abort message.

[7] Atomic commits are a common feature of version control software, and crucial for maintaining a consistent state in the repository.

Notable exceptions are CVS, VSS and IBM Rational ClearCase (when in UCM mode).

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.

[10] 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.

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.

If the error is to be rolled back, atomic commits again make the job much simpler.

This also reduces the risk of a developer accidentally removing unrelated changes that happened to be in the same commit.