严格事务调度

一次未决定的写像施工中的路段。严格调度不只禁止行人读取路面状态，也禁止另一施工队在上面继续覆盖；原事务提交或中止后，路段才重新开放。于是恢复管理器撤销一个 loser 时，不必担心别的事务已经在它的脏值上读写。

限制只跟随写集。两个只读事务可以同时访问，同一事务写 A 时，其他事务仍可处理无关的 B。性能取决于写热点与锁粒度，而不是简单地“严格就全部串行”。

严格性为恢复提供干净切口：写者若 abort，保护区间内没有外来读写需要解释；写者若 commit，后续访问从已决定版本继续。它不要求数据库页面从未包含脏字节，只要求逻辑访问权在决定前不交给其他事务。

若执行

w1(x,10); r2(y)->7; w2(y,8); c2; c1; r3(x)->10

$T_2$ 只访问 $y$，可以在 $T_1$ 未提交时完成；$T_3$ 对 $x$ 的读被放在 $c_1$ 后。调度严格而仍有并发。若把 $r_3(x)$ 移到 $c_1$ 前，就产生脏读；若换成 $w_3(x)$，则产生脏写，同样违规。

严格也不蕴含冲突可串行化。考虑

r1(x); r2(y); w1(y); c1; w2(x); c2

每次写后都没有其他事务在写者结束前访问同一项，所以调度严格；但 $r_2(y)$ 在 $w_1(y)$ 前给出 $T_2\to T_1$，$r_1(x)$ 在 $w_2(x)$ 前给出 $T_1\to T_2$，冲突图成环。要同时获得串行隔离，仍需另一条并发控制证明。

在页级锁实现中，对同页不同记录的更新也可能互相等待；这是保守的物理粒度，不改变逻辑定义。反过来，只锁记录而遗漏索引项或溢出页，可能让物理写绕过声明的严格保护。

多版本实现可以保留旧版本供读取，同时把新未提交版本隐藏；这种读取不访问 $w_i(x)$ 产生的版本，因而不违反严格性。若定义把“同一逻辑键的任何版本”都视作同一项，则结论会更强，文章必须声明版本粒度。

严格调度使 UNDO 更局部：崩溃恢复可以撤销未提交写，而不需要撤销已经读取或覆盖这些写的后继事务。它还禁止两笔未提交写互相覆盖，避免恢复时无法确定应恢复哪一个 before-image。

严格性、可串行化与持久性应分别测试。锁 trace 可证明未提交写未泄露，冲突图可证明串行次序，WAL 与重启 trace 则证明崩溃后的状态；任一证据都不能替代另外两项。

该层级的包含方向可用反例逐级验证：可恢复但有脏读的调度不是无级联；无级联但有脏写的调度不是严格。测试若只生成读依赖，会永远看不见第二个严格包含，因此还必须包含并发写写场景。