A transaction is a single logical unit of work, a sequence of reads and writes that must either all happen or none happen. The instant two transactions run at the same time on the same data, the database can quietly produce wrong answers unless a concurrency-control protocol stops it. This topic is about proving when interleaved execution is safe.
It is one of the most reliably tested areas in DBMS, and it is pure reasoning, no memorisation. If you can build a precedence graph and read a cycle, you can answer almost anything examiners ask. Let us build it up properly.
ACID: the four guarantees
Every transaction must preserve four properties, remembered as ACID.
Atomicity. All operations complete, or none do. A half-done funds transfer that debited one account but never credited the other is exactly what atomicity forbids. On failure the system rolls back.
Consistency. A transaction moves the database from one valid state to another, preserving every integrity constraint. What is true before must be true after.
Isolation. Concurrent transactions must not see each other's partial, uncommitted work. The result must be as if they ran one after another.
Durability. Once a transaction commits, its effects survive crashes, power loss, and restarts, because they are written to non-volatile storage.
Isolation is the property concurrency control actually enforces, and it is where the marks live.
Schedules: serial and concurrent
A schedule is a chronological ordering of the operations of a set of transactions. A serial schedule runs one transaction fully before the next begins, so it is trivially correct but slow, since nothing overlaps. A concurrent schedule interleaves operations to use the CPU and disk efficiently, but now correctness must be proven. The goal is a concurrent schedule whose result equals some serial schedule. That is what "serializable" means.
Conflict serializability
Two operations conflict when they come from different transactions, touch the same data item, and at least one is a write. So a read-write, write-read, or write-write pair on the same item conflicts; two reads never do. A schedule is conflict serializable if you can turn it into a serial schedule by swapping only non-conflicting adjacent operations.
We do not test that by hand. We build a precedence graph (also called a serializability graph).
A worked precedence-graph example
Consider three transactions and this schedule S over data items A and B, read left to right:
S: R1(A), W1(A), R2(A), W2(A), R2(B), W2(B), R3(B), W3(B)
Make one node per transaction: T1, T2, T3. Draw an edge Ti to Tj whenever an operation of Ti conflicts with a later operation of Tj on the same item.
On item A: W1(A) happens before R2(A) and W2(A). A write followed by a later conflicting operation of T2 gives an edge T1 to T2.
On item B: W2(B) happens before R3(B) and W3(B). That gives an edge T2 to T3.
There is no operation of T2 or T3 that precedes and conflicts with an earlier transaction, so no back edges.
The graph is T1 to T2 to T3.
[DIAGRAM: precedence graph. Three circular nodes labelled T1, T2, T3 left to right, a directed arrow from T1 to T2 and a directed arrow from T2 to T3, no cycle.]
The rule is exact: a schedule is conflict serializable if and only if its precedence graph is acyclic. This graph has no cycle, so S is conflict serializable. A topological sort of the graph gives the equivalent serial order: T1, T2, T3. If instead an item B conflict had forced an edge T3 to T1, the graph would contain a cycle T1 to T2 to T3 to T1, and the schedule would not be serializable. Draw the graph, look for a cycle, that is the whole method.
Two-phase locking (2PL)
A precedence graph tells you after the fact whether a schedule was safe. A protocol guarantees safety in advance. The standard one is two-phase locking. Every transaction acquires locks (shared for reads, exclusive for writes) in two strict phases:
Growing phase. The transaction may acquire locks but must not release any.
Shrinking phase. Once it releases its first lock, it may release more but can never acquire another.
The theorem worth knowing: any schedule produced by 2PL is conflict serializable. The catch is that basic 2PL can still cause cascading rollbacks and deadlocks. Strict 2PL, which holds every exclusive lock until the transaction commits or aborts, removes cascading rollbacks and is what most real database engines actually use.
Why it matters
A well-normalised schema, of the kind covered in normalization in DBMS, stores each fact once. Concurrency control is what lets many users read and write that schema at once without corrupting it. Lost updates, dirty reads, and unrepeatable reads are precisely the anomalies isolation and 2PL exist to stop.
Transaction questions in GATE, UGC NET and placements
GATE CS almost always includes a serializability question. You are handed a schedule and asked whether it is conflict serializable, and if so, for the equivalent serial order, exactly the precedence-graph procedure above. View versus conflict serializability and 2PL properties also appear. Our GATE CS exam category sequences this with the rest of DBMS.
UGC NET Computer Science leans conceptual: define ACID, distinguish the isolation anomalies, and state what 2PL guarantees. Precise definitions score.
Placement and company tests ask the applied version, what ACID means, what a deadlock is, and why databases use locking, often alongside a systems-design discussion. The "isolation as if serial" idea is the one interviewers want you to articulate.
KnowledgeGate's published question bank carries over two thousand DBMS questions, and transactions and serializability are among its densest sub-areas, so there is ample drill on these exact patterns.
Practise it, do not just read it
Serializability is understood by drawing graphs, not by rereading definitions.
Work the full topic with solved schedules on the Transaction Management learn module.
For GATE-depth DBMS across the whole syllabus, GATE Guidance by Sanchit Sir sequences transactions with indexing and normalization.
To time yourself under exam conditions, the GATE test series puts serializability questions on the clock.
Learn ACID cold, build the precedence graph for any schedule you meet, and remember that acyclic means serializable. Do that, and concurrency control stops being intimidating and becomes marks you can count on.