我正在使用 JPA 2.0（Hibernate 实现）、Spring 和 Wicket 构建一个应用程序。一切正常，但我担心我的表单行为是基于副作用。
作为第一步，我使用OpenEntityManagerInViewFilter。我的域对象是由LoadableDetachableModel它执行entityManager.find() in its load方法。在我的表格中，我包裹了一个CompoundPropertyModel围绕这个模型来绑定数据字段。
我关心的是表单提交操作。目前我的表单提交通过了结果form.getModelObject()进入一个带有注释的服务方法@Transactional。因为模型内的实体仍然附加到实体管理器，@Transactional注释足以提交更改。
这很好，直到我有多个表单对同一实体进行操作，每个表单都会更改字段的子集。是的，它们可以同时访问。我想到了一些选择，但我想知道我错过的任何想法以及有关管理此问题以实现长期可维护性的建议：
- 将我的实体分割成与编辑表单相对应的子组件，并创建一个主实体，将它们链接在一起形成一个
@OneToOne关系。导致表格设计丑陋，并且以后很难更改表格。
- 立即分离实体加载的实体
LoadableDetachableModel，并在服务层手动合并正确的字段。难以管理延迟加载，可能需要为每个表单提供专门的模型版本以确保加载正确的子实体。
- 在为表单创建模型时将实体克隆到本地副本，然后在服务层中手动合并正确的字段。需要实现很多复制构造函数/克隆方法。
- 使用Hibernate的
dynamicUpdate仅更新实体已更改字段的选项。导致整个应用程序出现非标准 JPA 行为。在受影响的代码中不可见，并且与 Hibernate 实现紧密相关。
EDIT
显而易见的解决方案是在加载实体（即行）以进行表单绑定时锁定该实体。这将确保拥有锁的请求干净地读取/绑定/写入，而不会在后台发生并发写入。这并不理想，因此您需要权衡潜在的性能问题（并发写入级别）。
除此之外，假设您对属性子组上的“最后写入获胜”感到满意，那么 Hibernate 的“dynamicUpdate”似乎是最明智的解决方案，除非您考虑很快切换 ORM。我觉得很奇怪，JPA 似乎没有提供任何允许您只更新脏字段的东西，并且发现将来很可能会这样做。
补充（我原来的答案）
与此正交的是如何确保当您的模型加载用于表单绑定的实体时打开事务。令人担忧的是，实体属性会在此时更新，并且在事务之外，这会使 JPA 实体处于不确定状态。
正如阿德里安在评论中所说，显而易见的答案是使用传统的每个请求交易过滤器。这保证了请求中的所有操作都发生在单个事务中。然而，它会确实对每个请求使用数据库连接。
有一个更优雅的解决方案，带有代码，here http://faler.wordpress.com/2009/04/30/building-a-more-scalable-open-session-in-view/。该技术是延迟实例化实体管理器，并仅在需要时（即，当第一次 EntityModel.getObject() 调用发生时）才开始事务。如果在请求周期结束时有一个事务打开，则该事务将被提交。这样做的好处是永远不会浪费任何数据库连接。
给出的实现使用 wicket RequestCycle 对象（请注意，这在 v1.5 及以后版本中略有不同），但整个实现实际上相当通用，因此您可以通过 servlet Filter 在 wicket 之外使用它（例如）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
