事务的属性--可恢复性（Recoverability）

可恢复性（Recoverability）

Recoverability means that committed transactions have not read data written by aborted transactions (whose effects do not exist in the resulting database states)。

可恢复性是并发的事务后期、表明提交阶段事务间相互影响的属性。即：已经提交的事务没有读过被撤销的事务的写数据。如果这样的事情发生了，则已经提交的事务读过被撤销的事务的写数据，则脏读异常发生，导致数据不一致。所以可恢复性属性保证的是多个事务并发调度后期的提交顺序对数据的一致性没有影响。

如表1-10，case 1的事务T2读数据X发生在事务T1写数据X之后，两个事务都提交，没有违反“可恢复性”的定义；case 2 的事务T2读数据X发生在事务T1写数据X之后，事务T1和T2都撤销，没有违反“可恢复性”的定义；所以case 1和case 2这两种调度方式都具有“可恢复性”。而case 3发生了脏读，所以不满足“可恢复性”。

 

表1-10 可恢复性示例

可恢复				不可恢复
case 1		case 2		case 3
T1	T2	T1	T2	T1	T2
R(X)		R(X)		R(X)
W(X)		W(X)		W(X)
	R(X)		R(X)		R(X)
	W(X)		W(X)		W(X)
Commit		Abort			Commit
	Commit		Abort	Abort

 

    前面我们说：可恢复性属性保证的是多个事务并发调度后期的提交顺序对数据的一致性没有影响。那么，如果可恢复性不被满足，即脏读发生，如表1-10的case 3，数据库系统的事务管理器应该怎么处理呢？答案是“回滚”，回滚事务T2以保证数据的一致性。

    由此又引发一个新的问题，称为“避免级联回滚（Avoids cascading aborts / rollbacks (ACA)）”，即事务管理器在做事务调度的时候，就要避免case 3的情况发生，以避免因为事务T1撤销而导致事务T2被迫被回滚掉。如果事务T2被迫被回滚掉，则称为事务T2因事务T1的撤销/回滚而被牵连即发生级联回滚。

    我们再来看表1-10中的case 2，事务T1撤销，但事务T1写数据X在事务T2读数据之前，所以事务T1发生回滚导致事务T2不得不回滚，这样才能保证数据的一致性。这说明尽管某个调度如case 2符合可恢复性，但是还是可能存在级联回滚的可能。而级联回滚会为数据库系统的事务管理器带来额外的操作进而影响效率，事务管理器应当在进行事务调度的时候，就采取措施避免发生级联回滚。所以，“避免级联回滚”成为了比“可恢复性”更为严格的一个事务属性。