4

我对 JPA 很陌生，阅读了这篇关于 JPA2.0 中锁定模式的文章，这给我留下了一个关于 LockModeType.OPTIMISTIC_FORCE_INCREMENT 的问题。

这是带有文章示例的图像：http: //i.stack.imgur.com/dFjhZ.jpg

到目前为止，我明白只有当我对实体 A 的更新取决于刚刚读取的另一个实体 B 的状态时，才需要在事务 T1 中显式乐观锁定。

我也明白使用 OPTIMISTIC_FORCE_INCREMENT 的锁会导致 B 更新它的版本属性，这将导致 OptimisticLockException 在所有尝试更新 B 并在发布锁之前读取它的事务中（即使用旧版本值）。

我的问题是：如果另一个事务 T2 在 B 的版本增加后立即开始，更改 B 并在 T1 提交之前完成，会发生什么？

据我了解，T1 应该得到一个 OptimisticLockException。如果是这样，这个锁定有什么意义，因为它只是略微减少了 T1 的易受攻击时间窗口？这意味着：如果我想确保在 T1 完成之前 B 不会改变，我需要一个悲观锁，对吗？

提前感谢您向我说明这一点:)

4

2 回答 2

2

您的示例问题突出显示了为什么这被称为“OPTIMISTIC”锁定。它并不完美，但如果足以满足现实世界中的大量情况，并且它使用的资源（包括时间）比硬锁少得多。

使用这种类型的锁定时，您是在为性能进行交易，并且通常会提高可用性，押注您的交易在大多数情况下都可以正常工作，并且您可以放心，在它不起作用的情况下' 将收到通知（将引发异常），然后您可以退后一步并“做正确的事情”：再试一次，放弃，......但是您选择处理异常。

悲观锁可能非常不适合需要某种级别锁定的高性能事务系统，但它们发生冲突的可能性很小：xTunes 的数百万用户中有多少（为了保护无辜而改名..）”订单”（更新）在任何时候，有多少都是从同一个帐户订购（更新）？

于 2013-03-09T00:49:22.097 回答
1

如果另一个事务 T2 在 B 的版本增加之后立即开始，更改 B 并在 T1 提交之前完成，会发生什么？

无论你要使用什么RDBMS，即使它使用MVCC（多版本并发控制）或2PL（两阶段锁定），当你改变一个表行时，都会获取一个排他锁，并且只有在当前运行时才释放事务结束（提交或回滚）。

因此，一旦您增加 B 的版本，在您提交交易之前，其他交易都无法更改该记录。

OPTIMISTIC_FORCE_INCREMENT还值得一提的是和之间的区别PESIMISTIC_FORCE_INCREMENT。OPTIMISTIC_FORCE_INCREMENT版本是否在事务结束时增加，而PESIMISTIC_FORCE_INCREMENT版本是否立即增加。

If there is heavy contention on that specific entity, then PESIMISTIC_FORCE_INCREMENT is much more appealing since once you acquired the lock, no other transaction is allowed to modify that record, and your transaction is not going to rollback due to optimistic version mismatch failures.

于 2016-10-25T06:44:17.043 回答