DBMS 中基于验证的协议

基于验证的协议也称为乐观并发控制技术。该协议在 DBMS(数据库管理系统)中用于避免事务中的并发。之所以称为乐观，是因为它做出了假设，即发生的干扰非常少，因此，在执行事务时不需要检查。

在这种技术中，在执行事务时不进行检查。在到达事务结束之前，事务中的更新不会直接应用于数据库。所有更新都应用于为事务保留的数据项的本地副本。在事务执行结束时，在执行事务时，验证阶段会检查是否有任何事务更新违反了可序列化性。如果没有违反可串行性，则提交事务并更新数据库；否则，事务被更新，然后重新启动。

乐观并发控制是一个三阶段协议。基于验证的协议的三个阶段：

1. 读取阶段：
   事务可以读取数据库中已提交数据项的值。更新仅适用于本地数据版本。
2. 验证阶段：
   执行检查以确保在将事务更新应用于数据库时没有违反可序列化性。
3. 写入阶段：
   在验证阶段成功时，将事务更新应用于数据库，否则，将丢弃更新并减慢事务。

乐观并发背后的想法是一次完成所有检查；因此事务执行以最小的开销进行，直到到达验证阶段。如果事务之间没有太大的干扰，大多数都会验证成功，否则，结果将被丢弃并稍后重新启动。这些情况对优化技术不太有利，因为不满足较少干扰的假设。

基于验证的协议对于罕见的冲突很有用。由于回滚中仅包含数据的本地副本，因此避免了级联回滚。这种方法不利于较长的事务，因为它们更容易发生冲突，并且可能会因与较短的事务冲突而反复回滚。

为了执行验证测试，每笔交易都应该经历如上所述的各个阶段。然后，我们必须了解以下三个时间戳，我们分配给交易T _I，检查它的有效性：

1. Start(T _i )： T _i开始执行的时间。

2. Validation(T _i )：这是T _i刚刚完成其读取阶段并开始其验证阶段的时间。

3、Finish(T _i )： _{T i}结束的时间是写阶段数据库中的所有写操作。

我们需要知道的另外两个术语是：

1. Write_set：一个事务的_{Write_set包含T i}执行的所有写操作。

2. Read_set：一个事务的读集，包含T _i执行的所有读操作。

_{在事务 T i}的验证阶段，协议检查 T _i不与当前处于验证阶段或已提交的任何其他事务重叠或干预。 _{T i}的验证阶段检查所有事务 T _{j 是否}必须满足以下条件之一才能被验证或通过验证阶段：

1. Finish(T _j )i ) ，因为T _j完成其执行意味着在T _i开始其执行(读取阶段)之前完成其写入阶段。然后确实保持了可序列化性。

2. T _I开始其写阶段T _J完成其写阶段之后，和T的read_set_我应该是不相交的有T _j的write_set。

3. T _{j在T i}完成其读取阶段之前完成其读取阶段，并且T _{i 的read_set 和write_set 与T j}的write_set 不相交。

例如：这里给出了两个交易 T _i和 T _j ，因为 TS(T _j )i )所以验证阶段在 Schedule-A 中成功。值得注意的是，最后对数据库的写操作是在 Ti 和 T _j都验证之后才进行的。由于 T _i在print(x+y)操作时读取 x(12)和y(15)的旧值，除非发生最终写入操作。

安排一个

Tj	Ti
r(x) // x=12
	r(x)
	x=x-10 r(y) //y=15
	y=y+10 r(x)
print(x+y)
	w(x) w(y)

Schedule-A is a validated schedule

优点：

1.避免级联回滚：这种基于验证的方案避免了级联回滚，因为只有在事务通过验证阶段后才会执行对数据库的最终写入操作。如果事务失败，则不会在数据库中执行更新操作。因此不会发生脏读，因此级联回滚的可能性为空。

2.避免死锁：由于使用了严格的基于时间戳的技术来维护事务的特定顺序。因此在这个方案中不可能出现死锁。

缺点：

1.饥饿：长期事务可能会饥饿，因为一系列冲突的短期事务会导致长期事务的重复重启顺序等等。为了避免饥饿，冲突事务必须暂时阻塞一段时间，让长期事务完成。