我正在使用 JPA 2.0(Hibernate 实现)、Spring 和 Wicket 构建应用程序。一切正常，但我担心我的表单行为是基于副作用。
作为第一步，我使用 OpenEntityManagerInViewFilter。我的域对象由 LoadableDetachableModel 获取，它在其 load 方法中执行 entityManager.find()。在我的表单中，我围绕此模型包装了一个 CompoundPropertyModel 以绑定(bind)数据字段。
我担心的是表单提交操作。目前，我的表单提交将 form.getModelObject() 的结果传递到一个用 @Transactional 注释的服务方法中。因为模型中的实体仍然附加到实体管理器，所以 @Transactional 注释足以提交更改。
这很好，直到我有多个对同一实体进行操作的表单，每个表单都会更改字段的一个子集。是的，它们可以同时访问。我想到了几个选项，但我想知道我遗漏的任何想法以及关于管理它以实现长期可维护性的建议:
- 将我的实体分割成与编辑表单相对应的子组件，并创建一个主实体，将它们链接在一起形成
@OneToOne关系。 导致表格设计丑陋，并且以后很难更改表格。 - 立即分离由
LoadableDetachableModel加载的实体，并手动合并服务层中的正确字段。 难以管理延迟加载，可能需要为每个表单提供专门版本的模型，以确保加载正确的子实体。 - 在为表单创建模型时将实体克隆到本地副本，然后手动合并服务层中的正确字段。 需要实现大量复制构造函数/克隆方法。
- 使用 Hibernate 的
dynamicUpdate选项只更新实体的更改字段。 在整个应用程序中导致非标准 JPA 行为。在受影响的代码中不可见，并导致与 Hibernate 实现的紧密联系。
最佳答案
编辑
显而易见的解决方案是在加载实体(即行)以进行表单绑定(bind)时锁定它。这将确保拥有锁的请求读取/绑定(bind)/写入干净，后台不会发生并发写入。这并不理想，因此您需要权衡潜在的性能问题(并发写入级别)。
除此之外，假设您对属性子组上的“最后一次写入获胜”感到满意，那么 Hibernate 的“dynamicUpdate”似乎是最明智的解决方案，除非您考虑很快切换 ORM。我觉得很奇怪，JPA 似乎没有提供任何允许您只更新脏字段的东西，并且发现它可能会在未来出现。
补充(我原来的回答)
与此正交的是如何确保在模型加载实体以进行表单绑定(bind)时打开事务。令人担忧的是，实体属性会在此时更新，并且在事务之外，这会使 JPA 实体处于不确定状态。
正如 Adrian 在他的评论中所说，显而易见的答案是使用传统的 transaction-per-request 过滤器。这保证了请求中的所有操作都发生在单个事务中。但是，它肯定会对每个请求使用数据库连接。
有一个更优雅的解决方案，使用代码，here .该技术是懒惰地实例化 entitymanager 并仅在需要时才开始事务(即，当第一次 EntityModel.getObject() 调用发生时)。如果在请求周期结束时有打开的事务，则将其提交。这样做的好处是永远不会有任何浪费的数据库连接。
给出的实现使用了 wicket RequestCycle 对象(注意这在 v1.5 之后略有不同)，但整个实现实际上相当通用，因此您可以(例如)通过 servlet Filter 与 wicket 一起使用它.
关于java - 如何控制 Wicket 表单中的 JPA 持久性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5350218/