我是JPA的新手,阅读了
this篇有关JPA2.0中锁定模式的文章,这给我留下了一个关于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没有改变我需要一个悲观的锁,对吧？

在此先感谢我明白:)

最佳答案 您的示例问题突出了为什么这称为“OPTIMISTIC”锁定.它并不完美,但如果足以满足现实世界中的大量情况,并且它比硬锁使用更少的资源(包括时间).

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

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