Serial Schedule

Definition

A serial schedule executes one transaction completely (all its operations, in order, ending with COMMIT or ABORT) before the next transaction begins even its first operation. There is zero interleaving — the transactions' operations never interleave in time.

Using the running example (T1 transfers ₹100 from A to B; T2 credits 10% interest on A and B; A=1000, B=2000 initially), there are exactly two possible serial schedules:

Serial schedule `<T1, T2>`:

R1(A) W1(A) R1(B) W1(B) COMMIT1   R2(A) W2(A) R2(B) W2(B) COMMIT2

Trace: A=1000→900 (withdraw 100), B=2000→2100 (deposit 100), T1 commits. Then T2 reads A=900→990 (×1.10), reads B=2100→2310 (×1.10), commits. Final: A=990, B=2310.

Serial schedule `<T2, T1>`:

R2(A) W2(A) R2(B) W2(B) COMMIT2   R1(A) W1(A) R1(B) W1(B) COMMIT1

Trace: A=1000→1100 (interest), B=2000→2200 (interest), T2 commits. Then T1 reads A=1100→1000 (withdraw 100), reads B=2200→2300 (deposit 100), commits. Final: A=1000, B=2300.

Notice the two serial schedules produce different final results (990/2310 vs. 1000/2300) — that is expected and fine. Serializability never claims all serial orders give the same answer; it only claims each serial order is, by definition, correct on its own terms, because it is exactly what you'd get if the transactions ran with no concurrency at all.

Why a Serial Schedule Is Always "Correct"

A serial schedule is correct by definition: since each transaction is assumed to be correct in isolation (it transforms a consistent database state into another consistent state when run alone), running transactions back-to-back with no interference trivially preserves that guarantee. There is no possibility of one transaction reading a partial, in-progress result of another, because no two transactions are ever "in progress" at the same instant.

The Cost

The price of this guaranteed correctness is that all concurrency benefits are given up. While T1 runs, T2 (and every other waiting transaction) sits completely idle even if T2 doesn't touch any data T1 is using. On a system with many short transactions and I/O waits, forcing serial execution can reduce throughput drastically — which is precisely the motivation, from 23.1, for wanting interleaved (non-serial) schedules that are still equivalent to some serial order.

Edge Cases

• With n transactions, there are n! possible serial schedules (orderings), and in general each can leave the database in a different final state — "serial" says nothing about which order is best, only that whichever order is chosen is internally consistent.
• A schedule can be serial even if the transactions do not touch the same data at all — seriality is purely about time (no overlap), not about data overlap.
• Systems occasionally fall back to serial (or near-serial) execution deliberately — e.g., taking an exclusive table-level lock for a bulk operation — trading concurrency for simplicity/safety in a narrow case.

Key Takeaways / Interview Angle

• Q: Are all serial schedules equivalent to each other? No — different serial orders can (and often do) produce different final database states, as shown above; each is simply self-consistent, not identical to the others.
• Q: What is a serial schedule used for in serializability theory? It is the reference/gold-standard against which non-serial schedules are judged: a non-serial schedule is "correct" precisely when it is equivalent to some serial schedule.