Spring Web Flow 2中流管理的持久化:事务性Web流的持久化策略 - 编程入门网
Exception 异常。
对于非原子 Web 流还是强烈推荐使用乐观锁来保护每个用户操作的数据完整性。实体的 @Version 字段是一个数据库生成的整数或时间戳且随后伴有更新操作时,需要显式地查询实体以便在持久化上下文中刷新其状态。否则,@Version 字段将带有陈旧的值而后续在不同事务中对同一实体的更新会导致 OptimisticLockingFailureException 异常。具有讽刺意味的是,这个异常将在没有多用户并发性的情况下发生。相反,在原子流中必须避免这种更新后查询,否则将发生提前刷新。毕竟,无论在原子 Web 流期间,在内存中对实体对象更新了多少次,流结尾处发生的 SQL 刷新只能看到实体实例的最后状态。 显然流作用域持久化上下文使原子和非原子 Web 流中的持久化编程更顺利、更简单。不使用流作用域持久化上下文对象的 Web 流中的持久化编程也是可行的,只是有很多障碍和缺陷。 不使用流作用域持久化上下文的持久化编程 在某些情况下,如 Hotel Booking 样例应用程序所示,可以在没有 <persistence-context/> 标签的情况下实现 Web 流。这种方法最明显的影响在原子 Web 流上,一旦省略了流作用域持久化上下文对象您就无法得到原子 Web 流了。我将在下文讨论其他不便之处。 持久化上下文作用域划定到数据库事务 不使用流作用域持久化上下文,通过 @PersistenceContext 注释注入的持久化上下文默认情况下作用域划定到数据库事务。要更好地理解这种操作的问题所在,请查看来自 Hotel Booking 样例应用程序的以下代码片段: 清单 3. Hotel Booking 中 “主流” 定义的代码片段
如果清单 3 中引用的 cancelBooking 方法定义如下: 清单 4. cancelBooking 方法
Spring Web Flow 2中流管理的持久化:事务性Web流的持久化策略(7)时间:2012-02-26 IBM Xinyu Liu那么运行此代码时我们将得到如下错误:
<on-render> 标签返回的 booking 实体会在后续操作 <transition on="cancelBooking"> 中分离。同一 bookingService bean 的两个方法 findBookings 和 cancelBooking 在不同的数据库事务下执行,因此与两个截然不同的持久化上下文对象相关联。一个持久化上下文管理的 booking 实体,从另一个持久化上下文的角度来看,是分离的。 为了规避这一问题,在清单 5 所示的实际 cancelBooking 方法中,同一 booking 实体在它被删除前通过其主键被重新加载。 清单 5. 修复的 cancelBooking 方法
|
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |