JPA 2.0 OPTIMISTIC_FORCE_INCREMENT的语义

Question

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

以下是文章中的示例图片：http://i.stack.imgur.com/dFjhZ.jpg

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

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

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

据我所知，T1应该得到一个OptimisticLockException。如果是这样，这个锁的重点是什么，因为它只是略微减少了T1的脆弱时间窗口？这意味着：如果我想确保在T1完成之前B没有改变我需要一个悲观的锁，对吗？

提前感谢我向我说明这一点：）

Answer 1

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

当使用这种类型的锁定时，您需要进行交易以获得性能，并且通常会提高使用能力，并认为您的交易在大多数情况下都能正常运行，并且您可以放心，在那些情况下工作你将收到通知（将抛出异常），然后你可以退后一步，“做正确的事”：再试一次，放弃，......但是你选择处理异常。

悲观锁可能非常不适合需要某种程度锁定的高性能事务系统，但它们碰撞的可能性很小：xTunes的数百万用户中有多少（名称已更改以保护无辜者）。 。）“订购”（更新）在任何时刻，以及从同一帐户订购（更新）的数量是多少？

Answer 2

  

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

无论您要使用哪种RDBMS，即使它使用MVCC（多版本并发控制）或2PL（两阶段锁定），当您更改表格行时，也会获取独占锁定并仅在当前正在运行的事务已结束（提交或回滚）。

因此，一旦您增加B的版本，在您提交交易之前，其他任何事务都不能更改该记录。

还值得一提的是OPTIMISTIC_FORCE_INCREMENT和PESIMISTIC_FORCE_INCREMENT之间的区别。 OPTIMISTIC_FORCE_INCREMENT版本会在交易结束时增加版本，而PESIMISTIC_FORCE_INCREMENT版本会立即提升版本。

如果该特定实体存在激烈争用，则PESIMISTIC_FORCE_INCREMENT更具吸引力，因为一旦获得锁定，就不允许其他事务修改该记录，并且您的事务不会因为乐观版本不匹配失败。