A transaction is a unit of work done against the database in a logical sequence. The sequence is extremely important in a transaction.
It is a logical unit of work that contains one or more SQL statements. The result of all these statements in a transaction either gets completed successfully (all the changes made to the database are permanent) or if at any point any failure happens it gets rollbacked (all the changes being done are undone).
Step 1: Read (A)
A = 1000
Step 2: A := A - 100
New Buffer: 900
Step 3: Write (A)
Push to Disk
System Crash
Failure after deduction but before credit.
Data Inconsistency (The Drift)
Initial Sum
1000+3000 = 4000
Crash Sum
900+3000 = 3900
100 units were deducted from A but never reached B because the credit instruction wasn't atomic. This violates Consistency.
Why do we perform operations in a Buffer first?
This is why we perform every intermediate operation in the Buffer/RAM itself. If any failure or issue occurs, we can Rollback easily without affecting the permanent data in the Database. Only when ALL operations are successfully completed, we Commit at the very last step to write the final result to the Disk.
To ensure integrity of the data, we require that the database system maintain the following properties of the transaction.
Either all operations of a transaction are reflected properly in the DB, or none are. (All or nothing).
PhonePay Example
When you send ₹500, either it is deducted from your account AND added to the friend, OR nothing happens. No "money vanished" state exists.
Integrity constraints must be maintained before and after the transaction. DB must be consistent.
Total Logic Example
If System Total is ₹3000. After a ₹500 transfer, the total must still be ₹3000. No money can be "created" or "destroyed" out of thin air.
Multiple transactions execute concurrently, but each transaction is unaware of others.
Shopkeeper Example
If two people pay a shopkeeper ₹100 via UPI at the same microsecond, the system ensures T1 finishes updating the balance before T2 starts. They don't interfere.
After a transaction completes successfully, changes are permanent even if system failures occur.
Power Failure Example
Once your PhonePay shows "Success", that record is written to the bank's hard disk. Even if the entire bank data center loses power a second later, your payment record is safe.
The very first state of the life cycle of the transaction, all the read and write operations are being performed here. If they execute without any error the T comes to Partially committed state. Although if any error occurs then it leads to a Failed state.
After transaction is executed the changes are saved in the buffer in the main memory. If the changes made are permanent on the DB then the state will transfer to the committed state and if there is any failure, the T will go to Failed state.
When updates are made permanent on the DB. Then the T is said to be in the committed state. Rollback can't be done from the committed state. New consistent state is achieved at this stage.
When T is being executed and some failure occurs. Due to this it is impossible to continue the execution of the T.
When T reaches the failed state, all the changes made in the buffer are reversed. After that the T rollback completely. T reaches abort state after rollback. DB's state prior to the T is achieved.
A transaction is said to have terminated if it has either committed or aborted.