JPA和乐观锁定模式
我在Oracle的博客上读到一篇关于JPA和锁定模式的文章。
我不完全理解optimized和optimistic_force_increment锁定模式类型之间的区别。
乐观模式：
当用户选择这种模式时，他必须将EntityManager的状态flush（）放到数据库中，以手动增加版本字段。因此，所有其他乐观事务都将失效（回滚）。在事务结束时还会对版本进行检查，以提交或回滚事务。
这似乎很清楚，但什么时候应该使用optimized模式与optimistic_force_increment模式？我看到的唯一标准是，当我希望事务优先于其他事务时，应用optimistic_force_increment模式，因为选择此模式将回滚所有其他正在运行的事务（如果我很了解mecanism的话）。
选择此模式而不是乐观模式是否有其他原因？
共有1个答案
通常情况下，您永远不会使用lock（）API进行乐观锁定。JPA将在任何更新或删除时自动检查任何版本列。
lock（）API用于乐观锁定的唯一目的是当您的更新依赖于另一个未更改/更新的对象时。这样，如果其他对象发生更改，您的事务仍然会失败。
何时这样做取决于应用程序和用例。乐观将确保在提交时未更新其他对象。OPTIMISTIC_FORCE_INCREMENT将确保其他对象尚未更新，并在提交时增加其版本。
-
我们有一个系统，我们偶尔会得到一个乐观的锁定异常。我们在代码中已经解决了这个问题，但现在我正在查看JPA 2，并看到它有一个用于处理这个问题的注释（@版本） 我们的问题是，一个表上有多个事务，如果表锁已满，则即使未对相同的记录进行更改，也会导致乐观锁定异常。 我们在JBoss 4.2服务器上使用hibernate，数据库可以是MySQL或SQL服务器。 如果改为使用@Version，这会在两个数据
-
当我试图理解基于版本的乐观锁定如何防止“最后提交获胜”问题和适当的覆盖时，我遇到了困难。 为了使问题更具体，让我们考虑以下使用 JDBC 的伪代码： 这里，如果其他事务会在更新和提交之间提交其更改呢？如果事务是并发的，那么第一个事务所做的更新尚未提交，因此第二个事务不可见（具有适当的隔离级别），因此第一个事务提交将覆盖第二个交易的更改，而不会出现任何通知或错误。 乐观锁定只是降低了问题发生的概率，
-
我不确定方法的设计是否恰当。 我们使用乐观锁定，将增量版本放置在每个实体上。这种实体的每次更新都是通过比较和交换算法执行的，该算法的成功与否取决于其他客户端是否同时更新实体。经典的乐观锁定，如hibernate。 我们还需要采取重新尝试的方法。我们使用基于< code>http的存储(etcd ),某些更新请求可能会超时。 这就是问题所在。如何结合乐观锁定和重试？这是我面临的具体问题。 假设我有一
-
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。 乐观锁与悲观锁的具体区别: http://www.cnblogs.com/Bob-FD/p/3352216.html
-
在多用户环境中，在同一时间可能会有多个用户更新相同的记录，会产生冲突，解决方案有两种：乐观锁、悲观锁。 悲观锁在这里不讲，自行Google。 乐观锁假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，不完整则更新失败。 乐观锁实现方式 使用整数表示数据版本号.更新时检查版本号是否一致,如果相等,则更新成功,且版本号+1.如果不等,则数据已经被修改过,更新失败。 使用时间戳来实现。 本质上也
-
使用JPA乐观锁定，我们可以通过@Version字段控制一个数据库表是否同时被另一个事务更新，从而允许在数据库中存储可靠的数据。 如果Java应用程序只有一个CRUD服务负责数据库中的特定实体，我们也可以同步它的方法并管理信息在数据库中的存储顺序。 所以我的问题是，这些场景之间有什么区别？是否存在任何性能优势或者甚至是可遵循的最佳实践？