几年前，在Java世界中，几乎所有的“企业”类项目都需要JPA与数据库进行通信，这几乎是显而易见的。 JPA是Joel Spolsky描述的“ 泄漏抽象 ”的完美示例。 刚开始时很棒而又容易，但最后很难调整和限制。 对于许多参与数据访问层的后端开发人员而言，日常工作是黑客并直接使用缓存，刷新和本机查询。 有足够的问题和变通办法来写一本专门的书“面向黑客的JPA”，但是在本文中，我将只关注并发实体处理。
让我们假设这种情况：我们有一个Person实体，该实体在某些业务流程中由某些服务更新。
@Entity
public class Person {@Id@GeneratedValueprivate Long id;private String uuid = UUID.randomUUID().toString();private String firstName;private String lastName;// getters and setters}为了忽略任何域的复杂性，我们正在谈论更新此人的名字和姓氏。 我们可以想象代码如下：
firstNameUpdater.update(personUuid, "Jerry");
lastNameUpdater.update(personUuid, "Newman");经过一段时间的业务决定，更新两个元素都需要花费太长时间，因此缩短工期成为当务之急。 当然，有很多不同的方法可以做到这一点，但让我们假设，这种特殊情况并发将解决我们的难题。 这似乎很容易-只需使用Spring和voilà中的@Async注释我们的服务方法即可解决问题。 真？ 根据乐观锁定机制的使用，我们这里有两个可能的问题。
- 使用乐观锁定，几乎可以肯定，我们将从其中一种更新方法中获得OptimisticLockException-一种将排名第二的方法。 与根本不使用乐观锁定相比，这种情况更好。
- 没有版本控制，所有更新将毫无例外地完成，但是从数据库加载更新的实体后，我们将仅发现一个更改。 为什么会这样呢？ 两种方法都更新了不同的字段！ 为什么第二笔交易覆盖了其他更新？ 由于泄漏的抽象:)
我们知道，Hibernate正在跟踪对我们实体所做的更改（称为脏检查）。 但是为了减少编译查询所需的时间，默认情况下，它在更新查询中包括所有字段，而不是仅包含已更改的字段。 看起来很奇怪？ 幸运的是，我们可以配置Hibernate以其他方式工作，并根据实际更改的值生成更新查询。 可以使用@DynamicUpdate批注启用它。 这可以被视为解决部分更新问题的方法，但是您必须记住这是一个折衷方案。 现在，此实体的每次更新都比以前更耗时。
现在让我们回到乐观锁定的情况。 老实说，我们想要做的通常与这种锁定的想法相反，这种锁定假定可能不会对该实体进行任何并发修改，并且在发生这种情况时会引发异常。 现在我们肯定要进行并发修改！ 作为一种快速的解决方法，我们可以从锁定机制中排除这两个字段（ firstName和lastName ）。 可以通过在每个字段上添加@OptimisticLock（excluded = true）来实现。 现在，更新名称将不会触发版本增加-它将保持不变，这当然可以成为许多令人讨厌且难以发现一致性问题的来源。
最后但并非最不重要的解决方案是旋转更改。 要使用它，我们必须将更新逻辑包装在循环中，并在发生OptimisticLock时在事务处理时进行更新。 效果越好，进程中涉及的线程越少。 所有这些解决方案的源代码都可以在我的GitHub的jpa-async-examples存储库中找到 。 只是探索提交。
等待-仍然没有适当的解决方案？ 实际上没有。 仅由于使用了JPA，我们才对并发修改问题的简单解决方案不了解。 当然，我们可以重塑我们的应用程序以引入一些基于事件的方法，但是上面我们仍然有JPA。 如果我们使用域驱动设计，则尝试通过使用OPTIMISTIC_FORCE_INCREMENT锁定来关闭整个聚合，只是要确保更改复合实体或向集合中添加元素会更新整个聚合，因为它可以保护不变量。 那么，为什么不使用任何直接访问工具，例如JOOQ或JdbcTemplate呢？ 这个主意很棒，但不幸的是，不能与JPA同时使用。 JOOQ所做的任何修改都不会自动传播到JPA，这意味着会话或缓存可能包含过时的值。
为了正确解决这种情况，我们应该将此上下文提取到单独的元素中，例如new table，它将直接由JOOQ处理。 您可能已经注意到，在SQL中进行这种并发更新非常容易：
update person set first_name = "Jerry" where uuid = ?;使用JPA抽象，它变成了非常复杂的任务，需要对Hibernate行为以及实现内部进行真正的深入了解。 综上所述，我认为JPA没有遵循“反应式”方法。 它是为解决某些问题而构建的，但是目前我们提出了不同的问题，而在许多应用程序中，持久性并不是其中之一。
翻译自: https://www.javacodegeeks.com/2015/11/jpa-in-case-of-asynchronous-processing.html
)
