把冲突视为需要校验的情况
并发访问若事先对所有相关数据加锁，可能引入等待与维护开销。乐观方法允许事务先推进，再检查其所依据的数据和修改是否仍能满足正确性要求，冲突时不让结果直接成为有效提交。
Kung与Robinson在1981年论文中研究这类方法，把效率前提与冲突较少的工作负载联系起来。乐观不是放弃一致性检查，而是改变检查与等待发生的位置；冲突频繁时，已做工作可能反复被丢弃。
参考：[1]
读取、验证与发布修改
原论文把事务组织为读取、验证和可能发生的写入阶段：读取阶段的修改先留在局部副本中，验证成功以后才发布到共享结构。系统记录读集合、写集合等信息，以判断并发事务的相互影响。
只看最终写入的对象是否改变，未必覆盖事务依赖。若一个决策读取多项数据，再修改其中一部分，正确验证还须考虑那些读取与其他事务修改之间的关系；事务级要求不能直接缩减为一个字段是否仍等于旧值。
参考：[1]
重试是协议的一部分
验证失败后，应基于合适的新状态重新执行需要重做的事务，而不是继续发布已经失去依据的旧结果。PostgreSQL的隔离文档也强调，遇到相应并发失败时要从头重试整个事务，而非只重发最后一条语句。
乐观方法可能减少某些锁等待，却仍有验证、版本信息与失败重做的成本。是否更快取决于冲突率、事务长度和实现；把它称为乐观，不能据此保证无锁、无饥饿或任何负载下都取得更高吞吐。