Spring延迟加载和声明式事务.doc

Spring+Hibernate延迟加载和声明式事务处理最终解决方案
一、 spring+hibernate时使用hibernate的延迟加载功能是存在的问题：
spring是一个设计层面的框架，他解决的是业务逻辑层和其他各层的松耦合问题，因此它将面向接口的编程思想贯穿整个系统应用。Spring的orm框架用来集成其他持久层框架，比如hibernate，spring-orm框架对hibernate的session进行了封装，我们可以很方便的通过继承这个封装类HibernateDAOSupport并注入hibernate的sessionFactory完成初始化，并调用其内置对象HibernateTemplate的封装方法来调用session的API而不用考虑到session的初始化和关闭以及事务处理等系统操作，这也是AOP思想的一种体现。Hibernate的延迟加载功能是指获取某个实体对象时并不从数据库中加载他的关联对象，而在实际获取关联对象的时候才从数据库中加载，这样做很好的节省了数据库资源但是前提是必须保持session处于打开状态，在所有操作完成后再关闭。Spring封装了session操作后很自然的要做到在方法调用的前后打开和关闭session，这样我们在通过HibernateTemplate的方法来获取实体对象以后session就已经关闭了，而这时候在调用获取关联对象的方法的时候就会抛出异常：

二、 如何解决
1、 openSessionInViewInterceptor
通过spring的控制层框架spring-mvc来处理控制层并通过拦截器openSessionInViewInterceptor改变spring调用session的流程。这里介绍最简单的spring-mvc的使用方法，首先和struts一样要定义一个HttpServlet来总体控制请求的处理类以及容器的初始化，struts是ActionServlet，Spring是DispatcherServlet，如图：

如同struts的控制器都继承于Action类一样，spring的控制器都要实现controller接口

我们通过注入的方式传入usersDAO进行数据操作（通常这个操作应该是放到Service层，这里为了方便讲解没有加入Service层），这个DAO是myeclipse自动生成的原封不动，这里不再贴出来了。
几句话的意思很清楚，调用findByID方法把ID为1000的用户实体查出来，这个时候按道理session已经关闭了，下面调用user.getNewses方法获取这个用户发布的新闻信息的一个set集合，打印条数，系统显示：

没有报session 已经关闭的错误，原因是spring-config中作了配置，在配置之前我们要对springmvc做一些初步的了解。
配合DispatcherServlet我们也要定义相关的映射，能够将请求跳转到对应的控制器，先看看usersDAO

然后是我们的控制器LoginSpring，这里没有对跳转作处理，因为我们的重点不是mvc而是解决延迟加载。

最后是我们的映射和针对这些控制器所配置的拦截器opensessioninviewinterceptor

这样配置了以后管理session的就不是我们的hibernatetemplate了而是我们配置的拦截器，他会保持session直到我们的控制器做完了所有的事情才关闭，也就是我们调用user.getNewses方法的时候还是打开的，因此能得到满意的结果。

2、 openSessionInViewFilter
当我们的系统的控制层要使用struts的时候，我们就不能使用spring的拦截器了，因个这个拦截器是基于DispatcherServlet的，我们只有在web.xml中配置过滤器来改变session的流程。首先简要介绍一下struts+spring集成，看看struts的配置文件：

将每个Action的type都设定为org.springframework.web.struts.DelegatingActionProxy，并在最下面配置spring的配置文件的路径，当我们要使用过滤器的时候这个配置文件必须只存放Action的实际映射，下面是spring-action.xml，里面只有一个action：

这里不需要指定id，只需要指定别名，这个别名会自动匹配struts配置文件中对应的path, DelegatingActionProxy会自动从插件所配置的spring配置文件中寻找匹配的bean并实例化，当然也会完成注入的过程。
知道怎么将两个框架正和使用以后，我们来配置过滤器，见web.xml：

这里使用过滤器的时候一定要附上所有spring配置文件并在web容器(tomcat)启动时加载和初始化。这里spring-action.xml存放的Struts的Action的映射，spring-config.xml中存放其他的bean。
最后再看看这个Action，和上面的一样的代码。

这样的话当我们使用延迟加载的时候调用的就是HibernateTamplate的代理类，能够让Spring在请求开始的时候打开Session，响应结束前关闭Session，这样就不会存在Session关闭的错误了。但是当我们增删改的时候，又会出现下面的问题：

为什么会有这样的问题呢，因为Hibernate有自己的事务策略，我们在Spring的OpenSessionInView中打开Session是以只读的方式来管理事务，这样进行增删改的时候就会出现错误。如何解决，先看看Spring的事务处理。
三、 声明式事务处理
声明式事务处理是springAOP思想的一个扩展，事务处理是一个典型的系统功能，因此通过将事务处理封装在一个切面中进行处理以分离具体业务操作和系统功能的方式是最好的设计层面的选择。
首先我们要配置一个PlatformTransactionManager接口的一个实现用来控制事务流程（commit和rollback）， 如果我们是spring+hibernate，框架集成的话，我们就要配置hibernate专用的PlatformTransactionManager实现:

我们模拟一个实例就是两个银行之间的转账，MsBankDAO民生银行DAO；ZsBankDAO招商银行DAO。这两个DAO都是用myeclipse生成，这里不作介绍，我们的业务逻辑对象BankBO的transferMoney方法来完成这个转账操作：

其中if语句中的两个操作就是一个典型的粗粒度事务，我们使用声明的方式来进行事务处理就无需在这里面加入任何关于事务的代码。
既然是使用AOP代理BO，我们就得有一个BankBOImpl的代理类：

然后我们模拟一个事故：

将民生银行的修改方法抛出一个错误
我们要传入被代理类的接口以及实现，建一个主函数来测试一下：

注意这里要通过代理类boProxy来返回BankBO的一个临时实现，运行结果：

在查看数据库中的数据并没有改变。

四、 解决ReadOnly事务策略问题
继续第二节我们的问题，Hibernate的事务策略是需要配置的，Spring为了能以AOP的方式来管理事务，就必须提供Hibernate事务策略和事务操作的封装，也就是我们上面提供的PlatFormTransactionManager接口的Hibernate持久层实现HibernateTransactionManager，
Spring在处理事务的时候会将这个底层的封装体传到TransactionTemplate进行初始化事务处理流程和参数，我们在看HibernateTeamplat是我们所熟知的Hibernate的Session的API的封装，他的父类HibernateAccessor中已经定义好了5种Hibernate的事务策略，其中就有Flush_NEVER策略和FLUSH_AUTO等策略，如果我们平时增删改的时候没有用到HibernateTamplate就会在操作的时候由Hibernate来管理事务，但这个时候由于Opensessioninview的缘故为了防止在延迟加载的时候改动持久层刷新策略已经被设定为Flush_Never，也就是说增删改的时候也会以只读的刷新模式来处理，这当然会报错，按照异常所说的要把前者换成后者就行了，但这样就没办法保证延迟加载的时候的安全性，因为很有可能这个PO对象会被传到View层被随意改动，如果能够在读的时候只读，在写的时候由能够及时刷新就能解决问题了，如果是编程式事务处理的话，我们就必须分别在查询和增删改的时候更换刷新模式，这将会很麻烦，还好Spring提供了声明式事务处理，提供了一种扩展性很高的解决方案。解决的方法很简单，让Spring来全权管理事务，在省事的同时也更好的划分了层次的关系，避免了Service层涉及事务策略这类的系统功能，将AOP思想体现的淋漓尽致。看看配置：

Find开头的方法被设定为只读，其他方法设定为auto（默认），让所有Service结尾的类的方法都处在事务中（包括不需要事务的方法），虽然消耗了一定的系统资源，但却让我们不必再为事务的问题操心，把精力集中到业务逻辑中。