乐观锁定绝对安全吗？

Question

当使用乐观锁定策略时，它可以解决如下并发问题：

| the first transaction started        |
|                                      |  
| select a row                         |
|                                      |  the second transaction started
| update the row with version checking |
|                                      |  select the same row 
| commit txn                           |
|                                      |  update the row with version checking
|                                      |  
|                                      |  rolls back because version is dirty

但是，如果在极少数情况下，如果第二个事务中的更新是在第一个事务中的udpate之后但在事务提交之前，该怎么办？

| the first transaction started        |
|                                      |  the second transaction started
| select a row                         |
|                                      |  select the same row 
| update the row with version checking |
|                                      |  update the row with version checking
| commit txn                           |
|                                      |  rolls back because version is dirty // will it?
|                                      |  
|                                      |  

我做了一个实验，第二个事务中的更新无法读取“脏”版本，因为第一个事务尚未提交。在这种情况下，第二次交易会失败吗？

Answer 1

正如您已经发现的，乐观锁受制于TOCTOU竞争条件:在提交决定和实际提交之前，有一个短暂的时间窗口，在此期间另一个事务可以修改数据。

为了使乐观锁定100%安全，您必须确保第二个事务一直等到第一个事务提交，然后才进行版本检查:

您可以通过在更新语句之前获取行级（选择更新）锁来实现这一点。

jOOQ为您做到这一点。在Hibernate中，您必须手动锁定该行：

var pessimisticRead = new LockOptions(LockMode.PESSIMISTIC_READ);
session.buildLockRequest(pessimisticRead).lock(entity);

请注意，您无法在单个VM上重现HiberNate中恼人的TOCTOU竞争条件。由于共享的持久上下文，HiberNate将顺利解决此问题。当事务在不同的VM上运行时，HiberNate无法提供帮助，您必须添加额外的锁定。

Answer 2

您在问题中没有说您实际使用的数据库系统，因此我不知道您的系统的详细信息。

但无论如何，在乐观锁定系统下，进程在执行更新语句时不能只检查行版本，因为这正是您担心的问题。

对于完全可序列化、隔离的事务，每个进程必须在提交时自动检查它检查和修改的所有行的行版本。因此，在您的第二个场景中，右手进程在尝试提交之前不会检测到冲突（您没有为右手进程包含这一步骤）。当它尝试提交时，它将检测到冲突并回滚。