A transaction either fully happens, or it never happened at all
A bank transfer is two updates that must succeed or fail together — never just one. This lesson defines a transaction formally, walks through its lifecycle states, and names the four ACID guarantees that make "all or nothing" real.
After this lesson
You should be able to
- Define a transaction and explain why it must be treated as one indivisible unit.
- Name the four ACID properties and what each one specifically guarantees.
A bank transfer is two updates that must never split apart
A transaction is a group of one or more database operations that must be treated as a single logical unit of work. Transferring 1000 rupees from Account A to Account B is two separate UPDATE statements — subtract from A, add to B — but from the application's point of view, and from the bank's, it is one operation: "transfer money." If the system crashes after the subtract but before the add, 1000 rupees has simply vanished from the world, which is unacceptable.
This is precisely the problem transactions solve: the DBMS guarantees that a transaction's operations either all take effect, or none do — there is no possible outcome where the money leaves A but never reaches B.
The states a transaction passes through
A transaction begins in the active state, executing its operations one by one. If every operation succeeds, it enters the partially committed state — logically done, but its changes may not yet be permanently saved to disk. From there it moves to committed, meaning its effects are now permanent and durable no matter what happens next, even a crash.
If any operation fails at any point, the transaction enters the failed state and moves to aborted, where every effect it had already made is undone — rolled back — as if it never ran at all. This rollback is what guarantees the "none do" half of the all-or-nothing promise.
ACID: four separate promises, easy to conflate
Atomicity is the all-or-nothing guarantee just described — implemented through the state machine above, typically using a log that records enough information to undo a partially finished transaction. Consistency means a transaction takes the database from one valid state to another, never violating a constraint like a CHECK or foreign key from Unit 3 midway through.
Isolation means each transaction behaves as if it were the only one running, even when many execute at the same time — the next lesson is devoted entirely to how this is actually implemented. Durability means once a transaction commits, its effects survive permanently, even a power failure immediately afterward — this is what makes "the money reached B" a promise you can actually trust.
Try it yourself
For an online exam system, describe one transaction (in terms of its individual database operations) and explain what atomicity specifically prevents from going wrong.
Need a hint?
Submitting an exam might involve saving the student's answers and marking their attempt as "submitted" — two separate writes that must not be allowed to split apart.
Check the worked solution
Submitting an exam is a transaction with two operations: INSERT the student's answers, and UPDATE their attempt status to 'submitted'. Atomicity prevents the scenario where the answers save but the status update fails (or the reverse) — without atomicity, a student could show as 'submitted' with no saved answers, or have answers saved that the system never counts as an official attempt.
Quick check
If a transaction's system crashes after it enters the partially committed state but before reaching committed, what should the DBMS do when it recovers?
Why this lesson exists
Syllabus mapping
Transaction Concept, Transaction State, Implementation of Atomicity and Durability
Maps to course outcome CO3.