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. Concurrency control is the machinery that proves 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.
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.
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 the schedule had instead opened with W3(A), that write would precede and conflict with R1(A), forcing an edge T3 to T1, and the graph would then contain a cycle T1 to T2 to T3 to T1, so 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.
Isolation anomalies: lost update, dirty read, unrepeatable read
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. Three anomalies are what it exists to stop, and examiners expect you to tell them apart.
Lost update. Two transactions read the same value, both compute from that copy, and the second write silently overwrites the first. Let A be a seat count of 10 and run R1(A), R2(A), W1(A), W2(A): both read 10, both write 9, two seats were sold and one was recorded. T1's update is lost.
Dirty read. T2 reads a value that T1 has written but not yet committed. If T1 then aborts, T2 has computed on a value that never existed in any committed state, and every write T2 derived from it is wrong too. That is where cascading rollback comes from.
Unrepeatable read. T1 reads A, T2 writes A and commits, then T1 reads A again and gets a different value inside one transaction. Any decision T1 made on the first read is no longer sound.
Put the lost-update schedule through the method above and the formalism agrees with the intuition. R1(A) precedes the conflicting W2(A), giving an edge T1 to T2; R2(A) precedes the conflicting W1(A), giving an edge T2 to T1. The precedence graph has a cycle, so R1(A), R2(A), W1(A), W2(A) is not conflict serializable. Strict 2PL stops all three anomalies, because a transaction holding its exclusive locks until commit can neither overwrite a value another transaction is still working from nor expose a write that has not committed.
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 DBMS question bank runs to over two thousand questions, with more than two hundred of them on transaction management and concurrency control alone, so there is ample drill on these exact patterns.
Practise serializability, 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.
