Suppose Account A has a balance of 400$ & B has 700$. Account A is transferring 100$ to Account B.
This is a transaction that has two operations a) Debiting 100$ from A’s balance b) Creating 100$ to B’s balance.
First operation passed successfully while second failed, in this case A’s balance would be 300$ while B would be having 700$ instead of 800$. This is unacceptable in a banking system.
The Atomicity property ensures that.
There are two key operations are involved in a transaction to maintain the atomicity of the transaction.
Abort: If there is a failure in the transaction, abort the execution and rollback the changes made by the transaction.
Commit: If transaction executes successfully, commit the changes to the database.
A transferring 1000 dollars to B. A’s initial balance is 2000 and B’s initial balance is 5000.
Before the transaction: Total of A+B = 2000 + 5000 = 7000$
After the transaction: Total of A+B = 1000 + 6000 = 7000$
For example account A is having a balance of 400$ and it is transferring 100$ to account B & C both. So we have two transactions here. Let’s say these transactions run concurrently and both the transactions read 400$ balance, in that case the final balance of A would be 300$ instead of 200$. This is wrong.
If the transaction were to run in isolation then the second transaction would have read the correct balance 300$ (before debiting 100$) once the first transaction went successful.
Once a transaction completes successfully, the changes it has made into the database should be permanent even if there is a system failure. The recovery-management component of database systems ensures the durability of transaction.