JPA 和乐观锁定模式 [英] JPA and optimistic locking modes

问题描述

我在 Oracle 博客这里上阅读了一篇关于 JPA 和锁定模式的文章.

我不完全理解 OPTIMISTIC 和 OPTIMISTIC_FORCE_INCREMENT 锁定模式类型之间的区别.

OPTIMISTIC 模式:

当用户使用此模式锁定实体时，在事务开始时对实体版本字段(@version)进行检查，并在事务开始时对版本字段进行检查.交易结束.如果版本不同，事务将回滚.

OPTIMISTIC_FORCE_INCREMENT 模式:

当用户选择这种模式时，他必须flush() EntityManager 的状态到数据库中以手动增加版本字段.因此，所有其他乐观事务都将失效(回滚).在事务结束时也会检查版本以提交或回滚事务.

看起来很清楚，但我应该什么时候使用 OPTIMISTIC 与 OPTIMISTIC_FORCE_INCREMENT 模式?我看到的唯一标准是当我希望事务优先于其他事务时应用 OPTIMISTIC_FORCE_INCREMENT 模式，因为选择此模式将回滚所有其他正在运行的事务(如果我很了解机制).>

选择这种模式而不是OPTIMISTIC模式还有其他原因吗?

谢谢

解决方案

通常情况下，您永远不会将 lock() API 用于乐观锁定.JPA 会在任何更新或删除时自动检查任何版本列.

lock() API 用于乐观锁定的唯一目的是当您的更新依赖于另一个未更改/更新的对象时.这允许您的事务在其他对象更改时仍然失败.

何时执行此操作取决于应用程序和用例.OPTIMISTIC 将确保在您提交时另一个对象尚未更新.OPTIMISTIC_FORCE_INCREMENT 将确保另一个对象尚未更新，并将在提交时增加其版本.

乐观锁总是在提交时验证，并且在提交之前不能保证成功.您可以使用flush() 提前强制数据库锁定，或者触发更早的错误.

I read an article on the blog of Oracle here about JPA and locking modes.

I don't entirely understand the difference between OPTIMISTIC and OPTIMISTIC_FORCE_INCREMENT lock mode types.

OPTIMISTIC mode :

When a user locks an entity with this mode, a check is done on the version field entity (@version) at the beginning of transaction and a check on the version field is also done at the end of the transaction. If versions are different, the transaction rolls back.

OPTIMISTIC_FORCE_INCREMENT mode :

When a user chooses this mode, he has to flush() the state of EntityManager into database to increment the version field manually. Thus, all other optimistic transactions will be invalidated (roll back). A check on the version is also done at end of transaction to commit or roll back transaction.

It seems clear but when should I use OPTIMISTIC versus OPTIMISTIC_FORCE_INCREMENT modes ? The only criteria that I see is to apply OPTIMISTIC_FORCE_INCREMENT mode when I want the transaction to have precedence over the others because choosing this mode will roll back all other running transactions (if I understand well mecanism).

Is there other reason to choose this mode rather than OPTIMISTIC mode?

Thanks

解决方案

Normally you would never use the lock() API for optimistic locking. JPA will automatically check any version columns on any update or delete.

The only purpose of the lock() API for optimistic locking is when your update depends on another object that is not changed/updated. This allows your transaction to still fail if the other object changes.

When to do this depends on the application and the use case. OPTIMISTIC will ensure the other object has not been updated at the time of your commit. OPTIMISTIC_FORCE_INCREMENT will ensure the other object has not been updated, and will increment its version on commit.

Optimistic locking is always verified on commit, and there is no guarantee of success until commit. You can use flush() to force the database locks ahead of time, or trigger an earlier error.

这篇关于JPA 和乐观锁定模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！