基于验证的协议也称为乐观并发控制技术。该协议在 DBMS(数据库管理系统)中用于避免事务中的并发。之所以称为乐观，是因为它做出了假设，即发生的干扰非常少，因此，在执行事务时不需要检查。
在这种技术中，在执行事务时不进行检查。在到达事务结束之前，事务中的更新不会直接应用于数据库。所有更新都应用于为事务保留的数据项的本地副本。在事务执行结束时，在执行事务时，验证阶段会检查是否有任何事务更新违反了可序列化性。如果没有违反可串行性，则提交事务并更新数据库；否则，事务被更新，然后重新启动。
乐观并发控制是一个三阶段协议。基于验证的协议的三个阶段：
- 读取阶段：
事务可以读取数据库中已提交数据项的值。更新仅适用于本地数据版本。 - 验证阶段：
执行检查以确保在将事务更新应用于数据库时没有违反可序列化性。 - 写入阶段：
在验证阶段成功时，将事务更新应用于数据库，否则，将丢弃更新并减慢事务。
乐观并发背后的想法是一次完成所有检查；因此事务执行以最小的开销进行，直到到达验证阶段。如果事务之间没有太大的干扰，大多数都会验证成功，否则，结果将被丢弃并稍后重新启动。这些情况对优化技术不太有利，因为不满足较少干扰的假设。
基于验证的协议对于罕见的冲突很有用。由于回滚中仅包含数据的本地副本，因此避免了级联回滚。这种方法不利于较长的事务，因为它们更容易发生冲突，并且可能会因与较短的事务冲突而反复回滚。
为了执行验证测试，每笔交易都应该经历如上所述的各个阶段。然后，我们必须了解以下三个时间戳，我们分配给交易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 )
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 )
安排一个
| 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.饥饿：长期事务可能会饥饿，因为一系列冲突的短期事务会导致长期事务的重复重启顺序等等。为了避免饥饿，冲突事务必须暂时阻塞一段时间，让长期事务完成。