Non Serial Schedule

Definition

A non-serial schedule interleaves the operations of two or more transactions in time — at least one operation of T2 executes between two operations of T1 (or vice versa). This is what actually happens whenever a DBMS runs multiple transactions concurrently, as motivated in 23.1.

Using the running example (T1 transfers ₹100 from A to B; T2 credits 10% interest on A and B), here is one possible non-serial schedule S1:

1. R1(A)
2. W1(A)
3. R2(A)
4. R1(B)
5. W2(A)
6. W1(B)
7. R2(B)
8. W2(B)

T1's and T2's operations are genuinely interleaved: T2's R2(A) and W2(A) land in the middle of T1's sequence (between T1's B-operations). This is not a serial schedule — neither transaction fully finishes before the other starts.

The Key Open Question

Unlike a serial schedule, which is correct by definition, a non-serial schedule's correctness is not automatic. It might still leave the database in a state that some serial execution of T1 and T2 could have produced (in which case it's just as good as a serial schedule, but faster) — or it might produce a state that no serial execution could ever produce, meaning the interleaving actually corrupted the logical result.

Determining which case a given non-serial schedule falls into is exactly what serializability (conflict serializability, 23.4, and view serializability, 23.5) is for. A non-serial schedule that is equivalent to some serial schedule is called serializable; the DBMS's concurrency control protocols (locking, timestamp ordering, etc.) exist specifically to only ever allow serializable non-serial schedules to occur, so the system gets interleaving's speed with serial execution's guarantees.

Worked Intuition on Schedule S1

Trace S1 with A=1000, B=2000: R1(A)=1000, W1(A)=900 (T1's withdrawal already applied), R2(A)=900 (T2 reads T1's already-updated A — not stale), R1(B)=2000, W2(A)=990 (T2 applies interest to 900), W1(B)=2100 (T1's deposit), R2(B)=2100 (T2 reads T1's already-updated B), W2(B)=2310 (T2 applies interest to 2100). Final: A=990, B=2310 — identical to serial <T1, T2>! Even though the operations interleaved in real time, the effective result matches a serial order because T2's reads of A and B always happened to land after T1 had already finished writing that particular item. This schedule turns out to be serializable — Topic 23.4 formalizes exactly why.

Edge Cases

• Not every interleaving is dangerous — as S1 shows, many non-serial schedules are perfectly safe and equivalent to a serial order; only some interleavings actually break correctness.
• A non-serial schedule can involve more than two transactions interleaving simultaneously; the analysis techniques (conflict/view serializability, precedence graphs) generalize to any number of transactions.
• The DBMS never has to "know" the semantics of the operations (e.g., that W(A) means "apply interest") to check serializability — it only needs to track which data items are read/written and in what order, which is what makes the theory purely operation-based rather than application-specific.

Key Takeaways / Interview Angle

• Q: Is a non-serial schedule always wrong or unsafe? No — many non-serial schedules are just as correct as a serial one; "non-serial" only describes the timing of operations, not correctness.
• Q: What decides whether a specific non-serial schedule is acceptable? Whether it is serializable — equivalent to some serial order of the same transactions — which is checked via conflict serializability (practical, used by real systems) or the more general view serializability (theoretical).