Strict Schedule

Definition

A schedule is strict if a transaction Tj is not permitted to read or write a data item that was written by another transaction Ti, until Ti has either committed or aborted. This is the strictest of the three properties in this mini-hierarchy: strict ⟹ cascadeless ⟹ recoverable (each implies the one after it, but not the reverse).

The key extra restriction beyond cascadeless: cascadelessness only cares about reads of dirty data; strictness also blocks writes to a data item another uncommitted transaction has already written (a blind-write-style conflict, "WW").

Worked Example — Cascadeless but NOT Strict

1. W1(A)          -> A=900 (uncommitted)
2. W2(A)          -> T2 OVERWRITES A to, say, 950 -- BEFORE T1 has committed or aborted
3. COMMIT1
4. COMMIT2

There is no dirty read here (T2 never reads A at all — it's a blind write), so this schedule is technically cascadeless (no reader depends on unresolved data). But it is not strict, because T2's write at step 2 happened while T1's write to the same item was still uncommitted. This matters most for recovery: if the DBMS needs to UNDO T1 (say T1 later aborts) by restoring A's before-image (its value before T1 wrote it), that undo would blindly stomp on T2's write too — because the system's undo logic doesn't "know" T2 already wrote a newer value on top. Recovering from failures becomes far more delicate when writes interleave like this.

Worked Example — Strict

1. W1(A)          -> A=900 (uncommitted)
2. COMMIT1        -> T1 commits (or could ABORT — either way, T1's fate is now settled)
3. W2(A)          -> T2 writes A only NOW, after T1's outcome is settled
4. COMMIT2

T2's write waits until T1 has fully committed (step 2) before touching A at all (step 3). If T1 had aborted instead, the DBMS would restore A to its pre-T1 value before T2 ever touches it — no ambiguity, no risk of stomping on someone else's uncommitted write.

Why Strict Is What Most Real Systems Provide

Strict schedules make recovery trivially simple: to undo an aborted transaction, the DBMS just restores the before-image of every item it wrote, with an ironclad guarantee that no other transaction has touched that item in the meantime (since strictness blocked them from doing so until the abort/commit was resolved). This is exactly what standard two-phase locking with exclusive locks held until commit/abort naturally provides: a transaction that writes A takes an exclusive lock on A and holds it until it commits or aborts, so nobody else can even read or write A during that window. Because it's both the easiest property to implement correctly via locking and gives the strongest safety guarantee, strictness is the de facto standard in production relational databases.

The Full Hierarchy

Strict ⊂ Cascadeless ⊂ Recoverable ⊂ (all schedules) — every strict schedule is cascadeless, every cascadeless schedule is recoverable, but the containments are all strict (proper) subsets, as the worked "X but not Y" examples across 23.7-23.9 demonstrate.

Edge Cases

• Strictness is orthogonal to serializability, exactly like recoverability and cascadelessness — a schedule can be strict yet not conflict-serializable, or conflict-serializable yet not strict; real systems (e.g., via strict two-phase locking) aim to guarantee both simultaneously.
• "Strict" here has nothing to do with SQL's "strict mode" settings — it's a formal scheduling property, a common point of confusion for learners encountering the term for the first time.

Key Takeaways / Interview Angle

• Q: What's the one extra thing strict adds over cascadeless? Blocking WRITES (not just reads) to a data item until the previous writer has committed or aborted — this closes the "blind write during someone else's uncommitted write" gap.
• Q: Why do most production DBMSs implement strict schedules rather than merely recoverable or cascadeless ones? Because strict schedules make crash recovery trivial (before-images can always be safely restored) and map naturally onto exclusive locks held until commit/abort — simplicity and safety together.