Why a database transaction groups several changes
A database transaction can make a group of changes succeed together or leave none of them applied. When moving a booking between rooms, deleting the old assignment without creating the new one would leave incomplete data. Atomic transactions prevent that particular partial result within the transaction's scope.
Go deeper
Treat related changes as one unit
Some operations require several database updates to represent one complete action. Moving a booking might involve removing one room assignment and adding another.
If a failure occurs between those changes, the database could otherwise retain an incomplete result. A transaction with atomicity commits the changes together or rolls them back together.
- Begin the transaction.
- Perform the related changes.
- Commit if the operation succeeds, or roll back if it fails.
Other transaction properties address issues such as durability and interference between concurrent operations. Atomicity specifically concerns the all-or-nothing boundary.
That boundary matters. Sending an email through an outside service is not automatically undone by rolling back a database transaction. Systems coordinating external actions need additional design beyond grouping database statements.