The Story That Explains a Transaction
Now imagine the power dies exactly between those two steps. Your money has left your account but never arrived in theirs. ₹5,000 has simply vanished. No bank on Earth would survive this. So the database treats both steps as one indivisible unit — either both happen, or neither does.
That single indivisible unit of work is called a transaction, and the four guarantees that keep it safe are the ACID properties.
A transaction is a logical unit of work that accesses and possibly modifies the contents of a database through a sequence of read and write operations. Crucially, a transaction is all-or-nothing: the database must never be left in a half-finished state where some operations applied and others did not.
A transaction is a sequence of one or more operations treated as a single, indivisible unit. It either completes entirely and makes its changes permanent (commit), or it has no effect at all (rollback / abort). There is no valid "partially done" outcome.
Transaction Concepts & Operations
Every transaction is built from a small set of low-level operations. Understanding these is the foundation for every practice problem that follows.
The Classic Fund-Transfer Transaction
Transaction T transfers ₹5,000 from account A to account B. Here it is written in SQL:
BEGIN TRANSACTION;
-- Step 1: take money out of A
UPDATE accounts SET balance = balance - 5000
WHERE acc_id = 'A';
-- Step 2: put money into B
UPDATE accounts SET balance = balance + 5000
WHERE acc_id = 'B';
-- Both succeeded -> make it permanent
COMMIT;
Expressed as abstract read/write operations, the same transaction looks like this:
If a crash occurs after Write(A) but before Write(B), ₹5,000 has been deducted but never credited. The database is now inconsistent. The whole reason transactions exist is to make this impossible — that guarantee is called Atomicity.
Transaction States & The State Diagram
During its lifetime, a transaction passes through a fixed set of states. Knowing the exact order — and which transitions are legal — is one of the most commonly tested topics in exams.
Every transaction ends in exactly one of two ways: Active → Partially Committed → Committed (the happy path), or it falls into Failed → Aborted (rolled back). Both paths converge on Terminated. A transaction can never go from Committed back to Active — once committed, it is final.
| State | Meaning | Can Transition To |
|---|---|---|
| Active | Executing read/write operations (initial state) | Partially Committed, Failed |
| Partially Committed | Final operation done; changes still in memory | Committed, Failed |
| Committed | Changes permanently saved — success | Terminated |
| Failed | Cannot continue normal execution | Aborted |
| Aborted | Rolled back to prior consistent state | Terminated (or restart) |
| Terminated | The transaction has left the system | — (final) |
The ACID Properties
ACID is the set of four guarantees a DBMS provides so that transactions remain reliable even with concurrency and system failures. Memorise the acronym: Atomicity, Consistency, Isolation, Durability.
Atomicity = all-or-nothing · Consistency = rules never broken · Isolation = transactions don't peek at each other · Durability = committed means committed forever.
Which Property Fails? — Before / After
The fastest way to truly understand ACID is to see what breaks when a property is missing. Using the fund-transfer (A→B of ₹5,000, starting A=10000, B=2000):
| Step | A | B |
|---|---|---|
| Start | 10000 | 2000 |
| Write(A) | 5000 | 2000 |
| 💥 CRASH | 5000 | 2000 |
| Result | 5000 | 2000 |
| Step | A | B |
|---|---|---|
| Start | 10000 | 2000 |
| Write(A) | 5000 | 2000 |
| ↺ ROLLBACK | 10000 | 2000 |
| Result | 10000 | 2000 |
On the left, ₹5,000 vanished (total dropped from 12000 to 7000) — both Atomicity and Consistency were violated. On the right, rollback restored the original consistent state. Total stays 12000 either way it should.
Practice Problems (Fully Solved)
Read each problem, attempt it on paper before revealing the reasoning, then check the worked solution. These are written in the style of typical university and competitive-exam questions.
Problem 1 — Identify the Violated Property
A transaction successfully commits and the system confirms it. Five minutes later the server loses power. On reboot, the committed changes are gone. Which ACID property was violated?
Problem 2 — The Lost Update (Isolation)
Two transactions run concurrently on the same item X = 100. Both read X, add 10, and write back, with operations interleaved as shown:
Expected final value: 120 (two increments of 10). Actual: 110. What problem is this, and which property prevents it?
Problem 3 — Legal or Illegal State Transition?
For each transition, decide whether it is a valid transaction state change:
| # | Transition | Valid? | Reason |
|---|---|---|---|
| a | Active → Partially Committed | YES | Happens after the final operation executes. |
| b | Active → Failed | YES | A crash or error during execution. |
| c | Committed → Active | NO | Commit is final; you cannot re-run a committed transaction. |
| d | Partially Committed → Committed | YES | Changes are flushed to stable storage successfully. |
| e | Failed → Committed | NO | A failed transaction must be Aborted, never committed. |
| f | Partially Committed → Failed | YES | Writing to disk can still fail at the last moment. |
Problem 4 — Why Does This Transaction Need Atomicity AND Durability?
An e-commerce checkout (1) deducts stock, (2) charges the card, (3) creates an order. The card charge at step 2 is rejected. What should happen, and which properties are at work?
Rapid-Fire Concept Check
Cover the right column and test yourself. These match the most frequently asked one-liners.
| Question | Answer |
|---|---|
| The initial state of every transaction | Active |
| State entered after the final operation, before disk write | Partially Committed |
| Property ensuring "all or nothing" execution | Atomicity |
| Property ensuring committed data survives a crash | Durability |
| Property preventing concurrent transactions from interfering | Isolation |
| Property keeping the database in a valid state | Consistency |
| Operation that makes changes permanent | Commit |
| Operation that undoes all changes | Rollback / Abort |
| The two final outcomes of any transaction | Committed or Aborted |
| Anomaly where one update overwrites another | Lost Update |