可恢复事务调度

把未提交值看成一张尚未兑现的支票。下游事务可以先拿它计算，却不能在支票兑现前把自己的结果标成不可撤销。否则上游一旦中止，下游已经对外承诺的结果便失去来源。

可恢复调度因此是一条“承诺不得超车”的规则，而不是“不许提前看”。更强的无级联调度会把读取本身推迟到写者提交之后；严格调度还会阻止覆盖未提交写。

这条规则保护的是 commit 的不可逆边界。消费者在内存中做了大量计算仍可撤销，只要尚未承诺；一旦它向客户端确认、释放依赖资源或触发不可回滚副作用，再要求它跟随上游 abort 就已经太晚。

调度

w1(x,20); r2(x)->20; c1; c2

是可恢复的。$T_2$ 读了 $T_1$ 的值，但 $c_1{<}_S{c}_2$。若 $T_1$ 在提交前失败，系统仍可令 $T_2$ 一起 abort；这会产生级联回滚，却没有撤销一个已经确认的 $T_2$。

把末尾改成

w1(x,20); r2(x)->20; c2; a1

便不可恢复。$T_2$ 已把依赖值作为提交结果发布，随后 $T_1$ 中止；单纯从磁盘删掉 $T_1$ 的写不能解释 $T_2$ 已产生的状态与外部响应。即使最终页面数值碰巧可修复，提交历史也已违约。

若 $T_2$ 只读取 $x$ 的初值，而 $T_1$ 在另一版本上写入，则不能仅因事件在时间上相邻就画 reads-from 边。多版本系统尤其需要版本标识，否则会把合法旧快照误判成脏依赖。

三级链更能看到级联成本：

w1(x); r2(x); w2(y); r3(y); a1

若允许这些脏读，$a_1$ 迫使 $T_2$ 中止，继而迫使 $T_3$ 中止。调度只要尚未出现 $c_2,c_3$ 仍可恢复，但已经完成的工作会成串丢弃；可恢复性没有承诺回滚代价小。

无级联事务调度公理库无级联事务调度Cascadeless transaction schedule · Cascadeless schedule · ACA schedule只允许事务读取已经提交事务产生的版本，从源头消除因脏读引发的级联中止。把 $c_i$ 放到依赖读之前，因此自动满足 $c_i<r_j(x)<c_j$，是可恢复调度的更强子类。恢复管理器若允许提前脏读，则必须保留依赖图，以便上游 abort 时递归中止所有尚未提交消费者。

可恢复性与持久日志仍是两件事。提交次序正确，却没有把 $c_i$ 持久化，崩溃后同样可能忘记写者；反过来，日志完整也不能把不可恢复的 $c_2<a_1$ 重新解释成合法承诺。

提交协调器可以按依赖图延迟消费者，将多个已经满足前置的事务批量刷入日志。优化不能颠倒边：group commit 可让 $c_i,c_j$ 共享一次 I/O，但若 $T_j$ 读取 $T_i$，稳定记录中仍须能恢复“$T_i$ 已提交后才承认 $T_j$”的逻辑次序。