延迟加载过滤器

Hibernate 允许对关联对象、属性进行延迟加载，但是必须保证延迟加载的操作限于同一个 Hibernate Session 范围之内进行。如果 Service 层返回一个启用了延迟加载功能的领域对象给 Web 层，当 Web 层访问到那些需要延迟加载的数据时，由于加载领域对象的 Hibernate Session 已经关闭，这些导致延迟加载数据的访问异常。

Spring 为此专门提供了一个 OpenSessionInViewFilter 过滤器，它的主要功能是使每个请求过程绑定一个 Hibernate Session，即使最初的事务已经完成了，也可以在 Web 层进行延迟加载的操作。

OpenSessionInViewFilter 过滤器将 Hibernate Session 绑定到请求线程中，它将自动被 Spring 的事务管理器探测到。所以 OpenSessionInViewFilter 适用于 Service 层使用HibernateTransactionManager 或 JtaTransactionManager 进行事务管理的环境，也可以用于非事务只读的数据操作中。

要启用这个过滤器，必须在 web.xml 中对此进行配置： 

… 

<filter> 

    <filter-name>hibernateFilter</filter-name> 

    <filter-class> 

    org.springframework.orm.hibernate3.support.OpenSessionInViewFilter 

    </filter-class> 

</filter> 

<filter-mapping> 

    <filter-name>hibernateFilter</filter-name> 

    <url-pattern>*.html</url-pattern> 

</filter-mapping> 

…



上面的配置，我们假设使用 .html 的后缀作为 Web 框架的 URL 匹配模式，如果您使用 Struts 等 Web 框架，可以将其改为对应的“*.do”模型。

OpenSessionInViewFilter是Spring提供的一个针对Hibernate的支持类，其主要意思是：当发起一个页面请求时，打开 Hibernate的Session，并一直保持住这个Session，直到这个请求结束。具体是通过一个Filter来实现的。
假设在你的应用中Hibernate是通过spring来管理它的session.如果在你的应用中没有使用OpenSessionInViewFilter或者OpenSessionInViewInterceptor。session会在transaction结束后关闭。
如果你采用了spring的声明式事务模式，它会对你的被代理对象的每一个方法进行事务包装（AOP的方式）。如下： 

<bean id="txProxyTemplate" abstract="true" 

        class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> 

        <property name="transactionManager" ref="transactionManager"/> 

        <property name="transactionAttributes"> 

            <props> 

                <prop key="save*">PROPAGATION_REQUIRED</prop> 

                <prop key="remove*">PROPAGATION_REQUIRED</prop> 

                <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> 

            </props> 

        </property> 

    </bean> 

    <bean id="manager" parent="txProxyTemplate"> 

        <property name="target"> 

            <bean class="org.appfuse.service.impl.BaseManager"> 

                <property name="dao" ref="dao"/> 

            </bean> 

        </property> 

    </bean>


目标类org.appfuse.service.impl.BaseManager 的  save *方法的事务类型PROPAGATION_REQUIRED  ，remove* 方法的事务类型PROPAGATION_REQUIRED
其他的方法的事务类型是PROPAGATION_REQUIRED,readOnly。
所以给你的感觉是调用这个名为“manager”的bean的方法之后session就关掉了。
如果应用中使用了OpenSessionInViewFilter或者OpenSessionInViewInterceptor，所有打开的session会被保存在一个线程变量里。在线程退出前通过
OpenSessionInViewFilter或者OpenSessionInViewInterceptor断开这些session。 为什么这么做？这主要是为了实现Hibernate的延迟加载功能。基于一个请求一个hibernate session的原则。
spring中对OpenSessionInViewFilter的描述如下：
它是一个Servlet2.3过滤器，用来把一个Hibernate Session和一次完整的请求过程对应的线程相绑定。目的是为了实现"Open Session in View"的模式。
例如： 它允许在事务提交之后延迟加载显示所需要的对象。
这个过滤器和 HibernateInterceptor 有点类似：它是通过线程实现的。无论是没有事务的应用，还是有业务层事务的应用（通过HibernateTransactionManager 或
JtaTransactionManager的方式实现）它都适用。在后一种情况下，事务会自动采用由这个filter绑定的Session来进行相关的操作以及根据实际情况完成提交操作。
警告： 如果在你的应用中，一次请求的过程中使用了单一的一个HIbernate Session，在这种情况下，采用这个filter会产生一些以前没遇到的问题。特别需要注意的是通过
Hibernate Session重新组织持久化对象之间关系的相关操作需要在请求的最开始进行。以免与已经加载的相同对象发生冲突。
或者，我们可以通过指定"singleSession"="false"的方式把这个过滤器调到延期关闭模式。这样在一次请求的过程中不会使用一个单一的Session.每一次数据访问或事务相关
操作都使用属于它自己的session(有点像不使用Open Session in View).这些session都被注册成延迟关闭模式，即使是在这一次的请求中它相关操作已经完成。
"一次请求一个session" 对于一级缓存而言很有效，但是这样可以带来副作用。例如在saveOrUpdate的时候或事物回滚之后，虽然它和“no Open Session in View”同样安全。
但是它却允许延迟加载。
它会在spring的web应用的上下文根中查找Session工厂。它也支持通过在web.xml中定义的“SessionFactoryBeanName”的init-param元素 指定的Session工厂对应的bean的
名字来查找session工厂。默认的bean的名字是"sessionFactory".他通过每一次请求查找一次SessionFactory的方式来避免由初始化顺序引起的问题（当使用ContextLoaderServlet
来集成spring的时候 ，spring 的应用上下文是在这个filter 之后才被初始化的）。
默认的情况下，这个filter 不会同步Hibernate Session.这是因为它认为这项工作是通过业务层的事务来完成的。而且HibernateAccessors 的FlushMode为FLUSH_EAGER.如果你
想让这个filter在请求完成以后同步session.你需要覆盖它的closeSession方法，在这个方法中在调用父类的关闭session操作之前同步session.此外你需要覆盖它的getSession()
方法。返回一个session它的FlushMode 不是默认的FlushMode.NEVER。需要注意的是getSession()和closeSession()方法只有在single session的模式中才被调用。
在myfaces的wiki里提供了OpenSessionInViewFilter的一个子类如下： 

public class OpenSessionInViewFilter extends org.springframework.orm.hibernate3.support.OpenSessionInViewFilter { 

       

        /** 

         * we do a different flushmode than in the codebase 

         * here 

         */ 

        protected Session getSession(SessionFactory sessionFactory) throws DataAccessResourceFailureException { 

                Session session = SessionFactoryUtils.getSession(sessionFactory, true); 

                session.setFlushMode(FlushMode.COMMIT); 

                return session; 

        } 

        /** 

         * we do an explicit flush here just in case 

         * we do not have an automated flush 

         */ 

        protected void closeSession(Session session, SessionFactory factory) { 

                session.flush(); 

                super.closeSession(session, factory); 

        } 

}