Spring Web Flow 2中流管理的持久化：事务性Web流的持久化策略 - 编程入门网

流管理持久化使用的这种方法与 JPA 1.0 解释对话处理的方式是完全一致的。JpaFlowExecutionListener 类是使这一切发生的底层 Spring Web Flow 组件。除了流管理持久化的非事务性数据访问方法之外，还可以使用只读事务。

Web 流中的只读事务

在某些情况下，与非事务性事务相比您可能更愿意使用只读事务。如果查看 Spring Web Flow 发行版中的样例 “Hotel Booking” 应用程序，会注意到在整个 “booking” Web 流期间，在全局范围内，对所有数据访问都使用了 @Transactional(readOnly=true)，无论操作的本质如何（读/插入/更新/删除）。

JPA 1.0 规范不支持只读事务，因此只有在某些 JPA 提供商中才能使用此设置。在其 JPA 实现中，Hibernate 将底层 Hibernate 会话的 FlushMode 设置为 MANUAL 并将 auto-commit 模式设置为 false。

流管理持久化的只读事务的表现与非事务性数据访问一样，只有在原子 Web 流结尾才会通过 <end-state commit="true"/> 刷新变更的实体。

如果希望刷新发生在 <end-state/> 之前，您需要在用 @Transactional 注释的 Spring bean 方法之一中调用 entityManager.flush()。

直接从 Web 流调用，<evaluate expression="persistenceContext.flush()"/>，行不通，因为没有事务绑定到任何 Spring Web Flow 标签，除了 <end-state commit="true"/>。您会得到以下错误消息：

"javax.persistence.TransactionRequiredException:　no　transaction　is　in　progress"　

本文稍后我们会回到 “Hotel Booking” 这个示例，来了解 没有流作用域持久化上下文的持久化编程 所面临的挑战。

Spring Web Flow 2中流管理的持久化：事务性Web流的持久化策略(4)

关于事务传播的更多信息

我已经介绍了事务如何根据其 propagation 属性的值进行传播，但是我忽略了一个特别的用例：如果标有 @Transactional(readOnly=true, propagation=Propagation.REQUIRED) 的方法要调用另一个标有 @Transactional(readOnly=false, propagation=Propagation.REQUIRED) 的方法，或者情况相反，那么事务又将如何传播呢？

Spring Web Flow 用一种简单而聪明的方式处理了这个问题：它忽略了第二个方法上的 readOnly 属性值。简而言之，初始化为只读的事务会保持只读状态，直到它结束，而且反之亦然。

这对于在流管理的持久化中是不使用事务还是使用只读事务的问题产生了有趣的影响。

只读事务的一个用例

应用程序服务层的 Spring bean 可以通过一些 JAX-WS/JAX-RS 注释公开为可重用的 SOAP/REST Web 服务。在这些 @Service bean 或其方法中应用 @Transactional 将 Web 服务调用与数据库事务绑定到了一起（没有明显的原因要在 DAO @Repository bean 上使用 @Transactional，除非应用程序具有级联式层架构，其中没有其他地方供开发人员指定事务属性）。

再思考一下 Spring Web Flow 中流管理持久化的非事务性数据访问方法。如果将 @Transactional 应用到启用了 Web 服务的 @Service bean，则非事务性上下文可能被覆盖。流作用域持久化上下文中的所有未决数据变更都会在方法调用链中遇到在服务层指定的读/写事务时刷新，这将导致所谓的 “提前刷新”。

避免提前刷新

如果在插入期间生成实体标识符（即标识列），即使在手动刷新情况下，刷新发生在调用 entityManager.

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!