Spring Web Flow 2中流管理的持久化：事务性Web流的持久化策略 - 编程入门网
| 整性而又无需在数据库中放置任何物理锁。尽管不是强制实施的，但是强烈建议在流管理的持久化中使用乐观锁。
持久化上下文在刷新时检查实体版本，如果检查出并发的修改，它就抛出 OptimisticLockingFailureException 异常（在 Hibernate 中是 StaleObjectException 异常）。实体在内存中存在的时间越长，其对应的数据库值被其他进程修改的可能性越大。 如上所述，在 Open Session in View 模式中，实体的持久状态受制于用户请求。一旦实体分离，通常需要在后续用户请求中进行合并/重新连接/重新加载操作来还原实体的持久状态，从而使实体与其对应的数据库值保持同步。 在流管理的持久化中，实体在多个用户请求之间保存其持久状态。在各用户请求之间没有强制执行数据库同步，因此很有可能出现 OptimisticLockingFailureException 异常。重要的是要优雅地处理 OptimisticLockingFailureException 异常，就像处理任何检查型业务异常一样。（即使 OptimisticLockingFailureException 是一个回滚到数据库事务的运行时异常，也应如此）。常用的策略是让用户有机会合并其变更或用未过期数据重启流。 Spring Web Flow 2中流管理的持久化：事务性Web流的持久化策略(2)时间:2012-02-26 IBM Xinyu Liu流作用域的持久化上下文 Web 流被声明为 XML 格式的流定义文件。带有 <persistence-context/> 标签的 Web 流启动时，会创建一个新的持久化上下文对象并将其绑定到流作用域。在等待用户请求时，该对象会断开与底层 JDBC 连接的连接并在服务于用户请求时重新连接。在整个流过程中都重用同一个持久化-上下文对象，这避免了分离实体状态的问题和相应的 LazyInitializationException 异常。 持久化上下文还被绑定到当前的请求线程并以两种方式公开给开发人员：作为隐式变量 persistenceContext 或通过 JPA @PersistenceContext 注释注入到任何 Spring bean 中。 隐式变量可以在流定义 XML 文件中直接得到，例如： <evaluate expression="persistenceContext.persist(transientEntityInstance)"/> 注入的 JPA 实体管理器可以在 Spring 组件的任何地方引用，比如在 DAO 中、服务 bean 或 Web 层 bean 中。 持久化上下文的类型：事务性或扩展型 @PersistenceContext 注释有一个可选的属性 type，该属性默认为 PersistenceContextType.TRANSACTION（也就是绑定到事务的持久化上下文）。在用流作用域的持久化上下文编程时必须使用此默认设置。在这种情况下，注入的绑定到事务的持久化上下文对象只是一个共享的代理，它透明地委托给了绑定到线程的实际的流作用域的持久化上下文。 选择另一个选项，也就是 PersistenceContextType.EXTENDED，会得到一个叫做 “扩展的实体管理器” 的东西，它对线程而言是不安全的，不能在并发访问的组件，比如单态 Spring bean，中使用。将扩展的实体管理器用作流作用域的持久化上下文会导致应用程序中出现不可预测的数据库/事务行为，因此要尽量避免使用它。 有趣地是，Seam 对话通常用注入到有状态会话 bean (EJB) 中的扩展的实体管理器实现。这是 Spring Web Flow 的流管理的持久化和 Seam 对话之间的一个显著区别。 流作用域的持久化上下文对象可以与 @Transactional 注释一起使用以调整流的持久化特征。 事务语义 作为 Spring 核心包一部分的 @Transactional 注释指定了注释的类或方法的事务语义。根据 Spring 开发团队所述，@Transactional 最好应用于具体类而不是接口。默认事务语义是：
readOnly：通过指定 @Transactional(read |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
