Introduction
A database transaction is a single logical unit of work — a group of read and write operations that must succeed or fail as a whole, never half-way. When a bank moves ৳5,000 from your account to a friend's, two operations happen: subtract from you, add to them. If the system crashes between these two steps, money must not simply vanish. The transaction abstraction guarantees this: either both happen or neither does.
For BCS, Bank IT, and IT-officer exams this is one of the highest-yield DBMS topics. Examiners love the ACID acronym, the difference between the four properties, concurrency problems (dirty read, lost update, phantom), isolation levels, schedules (serial, serializable, conflict-serializable), the precedence graph, two-phase locking (2PL), and deadlock handling. Almost every year at least one MCQ comes from here, and viva/written questions ask you to explain with an example. This lesson builds everything from first principles so you can answer any variation.
Learning objectives
- Define a transaction and its states, and read/write operations precisely.
- State and explain each of the four ACID properties with intuition and examples.
- Identify the classic concurrency anomalies: lost update, dirty read, non-repeatable read, phantom read.
- Distinguish serial, serializable, and conflict-serializable schedules and test serializability using a precedence (conflict) graph.
- Explain locking, 2PL and its variants, and how they guarantee serializability.
- Understand deadlock, its four conditions, detection (wait-for graph), prevention (wait-die, wound-wait), and timeouts.
- Map the four SQL isolation levels to the anomalies they allow or forbid.
- Explain recovery basics: the log, WAL, undo/redo, checkpoints.