Spring Web Flow 2 中流管理的持久化

核心提示： 再思考一下 Spring Web Flow 中流管理持久化的非事务性数据访问方法，如果将 @Transactional 应用到启用了 Web 服务的 @Service bean，Spring Web Flow 2 中流管理的持久化(9)，则非事务性上下文可能被覆盖，流作用域持久化上下文中的所有未

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

避免提前刷新

如果在插入期间生成实体标识符（即标识列），即使在手动刷新情况下，刷新发生在调用 entityManager.persist() 或 entityManager.merge() 方法后。这很有必要，因为持久化上下文中的每个托管（持久化）实体都必须被指定一个标识符。要避免这种提前刷新，需要将 ID 生成策略设置为 sequence。

另一方面，在视图层 Spring bean 上指定 @Transactional(readOnly=true) 将覆盖服务 bean 上的读/写事务设置；事务将保持只读状态以防止提前刷新。在 SOAP/REST Web 服务通信中绕过整个 Web 层的情况下，应用到服务 bean 的 @Transactional 注释确保 Web 服务调用运行在数据库事务内。

这是在流管理持久化中使用只读事务优于使用非事务性数据访问的地方。

如上所示，流管理持久化解决了涉及原子 Web 流的用例。本文剩余部分将重点介绍调用非原子 Web 流的用例，其中未应用流管理持久化。注意在其中的某些用例中我们仍然能够使用流作用域的持久化上下文对象。

非原子 Web 流

从业务流程管理 (BPM) 角度而言，一种长期运行的进程比典型的 Web 会话存活时间长。如果此类长期运行的进程涉及了人类的任务，则用户可以在该进程中工作任意长的时间，并且可以在几小时、几天甚至几个月之后回来恢复进程的执行。显然，此类进程应该在服务器崩溃时也可以存活。