Concurrent Execution

The Running Example for This Chapter

Every topic in Chapter 23 reuses the same two transactions on the same two bank balances, A and B (say A = ₹1000, B = ₹2000):

T1 (transfer ₹100 from A to B):        T2 (credit 10% interest on A and B):
1. R(A)                                1. R(A)
2. A = A - 100                         2. A = A * 1.10
3. W(A)                                3. W(A)
4. R(B)                                4. R(B)
5. B = B + 100                         5. B = B * 1.10
6. W(B)                                6. W(B)
7. COMMIT                              7. COMMIT

Keep this pair in mind for the rest of the chapter — every schedule, anomaly, and protocol below is just a different way of interleaving (or not interleaving) these fourteen operations.

Why Interleave at All?

A DBMS could, in principle, run T1 fully to completion and only then start T2 — no interleaving, no risk. But real workloads have hundreds or thousands of transactions arriving per second, and most transactions spend a large fraction of their time waiting — on disk I/O, on a network round trip, on a lock held by someone else. If the system executed transactions strictly one-at-a-time, the CPU would sit idle every time the current transaction blocked on I/O, and every other waiting transaction would be stuck behind it even though nothing but a disk read was in progress.

Concurrent execution means the DBMS interleaves the operations of multiple transactions — executing a few steps of T1, then switching to a few steps of T2, then back to T1, and so on — so that while T1 is waiting on disk, T2's CPU-bound work can proceed. This dramatically improves throughput (transactions completed per second) and average response time, which is why every production database interleaves transactions by default.

The Correctness Challenge

Interleaving is not free. If the DBMS interleaves T1's and T2's operations arbitrarily, the order in which reads and writes land can change the final values of A and B compared to running T1 and T2 one after another. For example, if T2's R(A) sneaks in between T1's R(A) and T1's W(A), T2 may compute interest on a stale value of A that T1 was about to overwrite anyway — producing a database state that no serial (one-at-a-time) execution of T1 and T2 could ever have produced.

This is the central problem concurrency control exists to solve: how do we get the performance benefit of interleaving while still guaranteeing the result is as correct as if the transactions had run one at a time? The rest of this chapter — serial vs. non-serial schedules, serializability, precedence graphs, and the recoverability hierarchy — is the formal machinery for answering exactly that question.

Edge Cases

• A single-user embedded database with no concurrent connections has no need for concurrency control at all — the problem only exists once two or more transactions can be "in flight" at once.
• Two transactions that touch completely disjoint data (T1 only touches A, T2 only touches C) can be interleaved in any order with zero risk — concurrency control machinery is only needed when transactions' data accesses overlap.
• Concurrency (interleaving) is not the same as parallelism (simultaneous execution on multiple cores) — even a single-core system interleaves transactions via time-slicing, and all the correctness issues in this chapter apply equally there.

Key Takeaways / Interview Angle

• Q: Why not just run every transaction serially and avoid this whole chapter? Because I/O-bound workloads would leave the CPU idle constantly, collapsing throughput and making every user wait far longer — concurrency is a performance necessity, not a convenience.
• Q: What is the DBMS actually trying to guarantee? That the observable result of any interleaved (concurrent) execution is equivalent to some serial execution of the same transactions — this property is called serializability, covered next.