A broader definition of correctness: if you understand what the application actually means, you can legally interleave schedules that conflict serializability rejects (56:23).
Example 1 — changing the aggregation makes the anomaly disappear
- Take the schedule from 08 that had a cycle, but change T2 from "compute the sum of A and B" to "count how many accounts have a balance ≥ 0" (
55:11,55:37). - Assuming balances stay non-negative after the $10 debit, the count is identical under any interleaving (
56:00). - So the schedule is equivalent to a serial ordering even though the dependency graph still has a cycle (
56:00).
Example 2 — blind writes
- Blind write: writing an object without ever reading it first (
56:56). - Schedule: T1 does
R(A) W(A), T2 doesW(A), T3 doesW(A). The dependency graph is full of cycles (57:28). - But the only thing that survives is whatever T3 wrote last — so the schedule is view equivalent to the serial order T1 → T2 → T3 (
57:52,58:22).
Why nobody implements it
- View serializability admits all conflict-serializable schedules plus more, especially those with blind writes (
58:22). - It requires static analysis of the application, or "talking to a human — the worst thing to do." That is why no system actually supports it (
58:50). - It is taught because it shows correctness is not one fixed idea and that more parallelism is theoretically available beyond 2PL, MVCC and OCC (
46:21).
The hierarchy of schedules
Nested from smallest to largest (1:01:30, 1:01:48):
flowchart TD
ALL[All possible schedules]
ALL --> V[View serializable]
V --> C[Conflict serializable ← what real systems give you]
C --> S[Serial schedules]
- Beyond view serializable there are further categories the course ignores (
1:01:48). - Next class adds another overlapping category around all of these — schedules that avoid cascading aborts, which includes some non-serializable schedules (
1:02:07). - When you ask a real system for serializable, you get the conflict serializable boundary (
1:02:22).