Seam的事务管理

分析Seam的事务管理之前有必要先写点SSH中的事务管理，Spring靠什么起家？靠IOC和AOP，通过这个IOC，Spring整合了大堆大堆的框架，于是成为了一个平台，让SSH程序员到处都是，但是我用Spring始终觉得有疙瘩，即便Spring是一个音乐家写的，Spring的源码很漂亮，测试代码很漂亮，用它也做了N多项目。

 

Spring，无状态全栈式JavaEE编程平台，事务用它的PlatformTransactionManager抽象把边界定在了一个方法的执行前和执行后，这在表达业务的原子上非常直观，比如我们把事务界定到应用层，然后领域层和数据访问层都不需要管理事务，可是当这个事务方法执行完之后spring就不管了，这就是问题所在，一个数据库交互的web应用如果有用户等待，网络异常，ORM几个因子在里面，就比较复杂，这也是OSIV的问题，见我的博文再说OSIV。

 

Seam意识到事务不仅仅在业务层，而且整个请求都应该有，这也许就是Gavin King的世界观，把ORM的关注点向表现层拉通，一条龙，而不是像Spring那样用一个无状态IOC今天集成这个，明天集成那个，Seam的事务具备真正意义上的全局性，借助JSF的生命周期，Seam对请求的没个阶段做了细粒度的控制，持久化上下文，事务范围，异常捕获，回滚操作，一切尽在掌握，Seam为了保护持久化操作，为每个请求打开了两个事务，如果触发页面动作，就是三个，第一个事务在恢复视图之前或者应用请求值之前启动，然后延伸到Invoke Application完成，另一个事务在渲染阶段打开，这样延迟加载及其他按需抓取保持隔离，以避免事务隔离级别的实效。

事务是反伸缩性的，但是在开发企业程序的时候，这是必须得谨慎注意的一块，程序如果严重依赖数据库将遇到伸缩性瓶颈，Seam通过对话模型，将数据和一致性控制拉到了内存中，这有效的避开了数据库的瓶颈，互联网开发似乎对事务的要求是不高的，比如易趣不会使用分布式事务这种技术。

 

通过查看Seam的日志，我发现即便一个JS的请求，Seam也会同样有多个事务的打开和关闭，这和我们OSIV配置，不小心导致请求一个js都打开Session和关闭Session何其相似？这个目前没想明白，等想明白了再来修改这篇文章。