Recoverability

回復可能性．

停電やメディア障害，プロセス停止からの回復(Recovery)と混同されがちだが，関係ない．

「何が起こってもデータベースのConsistencyを維持できるか」という意味．

「何が起こっても」にはConcurrency ControlによるAbortなども含まれる．

ここではその内容を引用して解説する．

Recoverable

$ for\ all\ t_i, t_j \in trans(s), if\ t_i\ reads\ from\ t_j\ in\ s\ and\ c_i \in op(s), then\ c_j <_s c_i

つまり，readしたトランザクションは，読んだ値をwriteしたトランザクションより先にコミットしてはならない．

これに違反するのはたとえば以下

$ w_1(x_1) r_2(x_1) c_2

Avoiding Cascading Aborts

$ for\ all\ t_i, t_j \in trans(s), if\ t_i\ reads\ x\ from\ t_j\ in\ s\ and\ c_i \in op(s), then\ c_j <_s r_i

つまり，readしたトランザクションは，必ずcommit済みのwriteを読む．

これに違反するのはたとえば以下

$ w_1(x_1) r_2(x_1)

Strictness

$ for\ all\ t_i \in trans(s),\ and\ for\ all\ p_i(x) \in op(t_i), p \in \{r,w\},

$ if \ w_j(x) <_s p_i(x),\ then\ a_j <_s p_i(x) \vee c_j <_s p_i(x).

つまり，あるトランザクションのwriteに対して自分がread/writeした場合，そのトランザクションの全ての命令とコミット，アボートが終わってから自分のread/write命令が実行されている，という制約．

この縛りがあるとリカバリが簡単になる

Undo logがよりシンプルになる．実行中のものはundo，というだけで済む

Avoiding Cascading Aborts....までの縛りだと，write-writeと連続した場合undoが複雑．

Regorousness

strictnessに加えて以下を満たす

$ for\ all\ t_i, t_j \in trans(s),

$ if \ r_j(x) <_s w_i(x),\ then\ a_j <_s w_i(x) \vee c_j <_s w_i(x).

つまり，あるトランザクションのreadに対して自分がwriteした場合，そのトランザクションが終了してから自分のwriteが実行される，ということ．