如何在应用层正确实现乐观锁？

Question

我对为什么乐观锁定实际上是安全的感到有些困惑。 如果我用更新时的版本检查检索时的版本，如果操作系统发出中断并在提交实际发生之前交换进程，我似乎仍然可以有两个请求进入更新块。 例如：

latestVersion = vehicle.getVersion();
if (vehicle.getVersion() == latestVersion) {
    // update record in database
} else {
    // don't update record 
}

在此示例中，我尝试在 Java 应用程序中手动使用乐观锁定，而不使用 JPA / Hibernate。 但是，似乎两个请求可以同时进入if块。 你能帮我理解如何正确地做到这一点吗？ 对于上下文，我还以Java Design Patterns网站为例。

Answer 1

嗯...这是乐观的部分。 乐观的是它是安全的。 如果你必须确定它是安全的，那么这并不乐观。

您展示的示例肯定容易受到竞争条件的影响。 不仅因为线程调度，还因为事务隔离级别。

MySQL 中的简单读取，在默认事务隔离级别 REPEATABLE READ 中，将读取在事务开始时提交的数据。

而更新数据将作用于更新时提交的数据。 如果其他一些并发 session 同时更新了数据库中的行并提交了它，那么您的更新将“看到”最新提交的行，而不是您的 get 方法查看的行。

避免竞争条件的方法是不要乐观。 相反，强制对记录进行独占访问。 Doveryai，没有证明。

如果您只有一个应用程序实例，您可能会为此使用关键部分。

如果你有多个app实例，临界区不能协调其他实例，所以需要在数据库中协调。 您可以通过使用悲观锁定来做到这一点。 要么使用锁定读取查询读取记录，要么您可以使用MySQL 的用户定义锁。