OpenSessionInViewFilter作用及配置

一、作用



Spring为我们解决Hibernate的Session的关闭与开启问题。

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



(eg： org.hibernate.LazyInitializationException:(LazyInitializationException.java:42)

- failed to lazily initialize a collection of role: cn.easyjava.bean.product.ProductType.childtypes, no session or session was closed

org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: cn.easyjava.bean.product.ProductType.childtypes, no session or session was closed)



用来把一个Hibernate Session和一次完整的请求过程对应的线程相绑定。目的是为了实现"Open Session in View"的模式。例如： 它允许在事务提交之后延迟加载显示所需要的对象。



而Spring为我们提供的OpenSessionInViewFilter过滤器为我们很好的解决了这个问题。OpenSessionInViewFilter的主要功能是用来把一个Hibernate Session和一次完整的请求过程对应的线程相绑定。目的是为了实现"Open Session in View"的模式。例如： 它允许在事务提交之后延迟加载显示所需要的对象。

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







二、配置



它有两种配置方式OpenSessionInViewInterceptor和OpenSessionInViewFilter(具体参看SpringSide)，功能相同，只是一个在web.xml配置，另一个在application.xml配置而已。



Open Session In View在request把session绑定到当前thread期间一直保持hibernate session在open状态，使session在request的整个期间都可以使用，如在View层里PO也可以lazy loading数据，如 ${ company.employees }。当View 层逻辑完成后，才会通过Filter的doFilter方法或Interceptor的postHandle方法自动关闭session。



OpenSessionInViewInterceptor配置



<beans>



<bean name="openSessionInViewInterceptor"



class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">



<property name="sessionFactory">



<ref bean="sessionFactory"/>



</property>



</bean>



<bean id="urlMapping"



class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">



<property name="interceptors">



<list>



<ref bean="openSessionInViewInterceptor"/>



</list>



</property>



<property name="mappings">



...



</property>



</bean>



...



</beans>



OpenSessionInViewFilter配置



<web-app>



...



<filter>



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



<filter-class>



org.springframework.orm.hibernate3.support.OpenSessionInViewFilter



</filter-class>



<!-- singleSession默认为true,若设为false则等于没用OpenSessionInView -->



<init-param>



<param-name>singleSession</param-name>



<param-value>true</param-value>



</init-param>



</filter>



...



<filter-mapping>



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



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



</filter-mapping>



...



</web-app>







三、注意事项



很多人在使用OpenSessionInView过程中提及一个错误：



org.springframework.dao.InvalidDataAccessApiUsageException: Write operations are not allowed in read-only mode (FlushMode.NEVER) – turn your Session into FlushMode.AUTO or remove ‘readOnly’ marker from transaction definition



看看OpenSessionInViewFilter里的几个方法



protected void doFilterInternal(HttpServletRequest request,



HttpServletResponse response,FilterChain filterChain)



throws ServletException, IOException {



　SessionFactory sessionFactory = lookupSessionFactory();



　logger.debug("Opening Hibernate Session in OpenSessionInViewFilter");



　Session session = getSession(sessionFactory);



　TransactionSynchronizationManager.bindResource(



　　sessionFactory, new SessionHolder(session));



try {



filterChain.doFilter(request, response);



}



finally {



　TransactionSynchronizationManager.unbindResource(sessionFactory);



logger.debug("Closing Hibernate Session in OpenSessionInViewFilter");



closeSession(session, sessionFactory);



　}



}



protected Session getSession(SessionFactory sessionFactory)



throws DataAccessResourceFailureException {



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



　 session.setFlushMode(FlushMode.NEVER);



　 return session;



}



protected void closeSession(Session session, SessionFactory sessionFactory)



throws CleanupFailureDataAccessException {



　 SessionFactoryUtils.closeSessionIfNecessary(session, sessionFactory);



}



可以看到OpenSessionInViewFilter在getSession的时候,会把获取回来的session的flush mode 设为FlushMode.NEVER。然后把该sessionFactory绑定到 TransactionSynchronizationManager，使request的整个过程都使用同一个session，在请求过后再接除该 sessionFactory的绑定，最后closeSessionIfNecessary根据该 session是否已和transaction绑定来决定是否关闭session。在这个过程中，若HibernateTemplate 发现自当前session有不是readOnly的transaction，就会获取到FlushMode.AUTO Session，使方法拥有写权限。



public static void closeSessionIfNecessary(Session session, SessionFactory  sessionFactory)



throws CleanupFailureDataAccessException {



if (session == null ||



TransactionSynchronizationManager.hasResource(sessionFactory)) {



return;



}



logger.debug("Closing Hibernate session");



try {



session.close();



}



catch (JDBCException ex) {



// SQLException underneath



throw new CleanupFailureDataAccessException("Could not close Hibernate session", ex.getSQLException());



}



catch (HibernateException ex) {



throw new CleanupFailureDataAccessException("Could not close Hibernate session",  ex);



}



}



也即是，如果有不是readOnly的transaction就可以由Flush.NEVER转为Flush.AUTO,拥有 insert,update,delete操作权限，如果没有transaction，并且没有另外人为地设flush model的话，则doFilter的整个过程都是Flush.NEVER。所以受transaction保护的方法有写权限，没受保护的则没有。



采用spring的事务声明,使方法受transaction控制



<bean id="baseTransaction"



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



abstract="true">



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



<property name="proxyTargetClass" value="true"/>



<property name="transactionAttributes">



<props>



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



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



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



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



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



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



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



</props>



</property>



</bean>



<bean id="userService" parent="baseTransaction">

<property name="target">



<bean class="com.phopesoft.security.service.impl.UserServiceImpl"/>



</property>



</bean>



对于上例，则以save,add,update,remove开头的方法拥有可写的事务，如果当前有某个方法，如命名为importExcel()，则因没有transaction而没有写权限，这时若方法内有insert,update,delete操作的话，则需要手动设置flush model为Flush.AUTO,如



session.setFlushMode(FlushMode.AUTO);



session.save(user);



session.flush();







尽 管Open Session In View看起来还不错，其实副作用不少。看回上面OpenSessionInViewFilter的doFilterInternal方法代码，这个方法实际上是被父类的doFilter调用的，因此，我们可以大约了解的OpenSessionInViewFilter调用流程:



request(请求)->open session并开始transaction->controller->View(Jsp)->结束transaction并 close session.



一切看起来很正确，尤其是在本地开发测试的时候没出现问题，但试想下如果流程中的某一步被阻塞的话，那在这期间connection就一直被占用而不释放。最有可能被阻塞的就是在写Jsp这步，一方面可能是页面内容大，response.write的时间长，另一方面可能是网速慢，服务器与用户间传输时间久。当大量这样的情况出现时，就有连接池连接不足，造成页面假死现象。



Open Session In View是个双刃剑，放在公网上内容多流量大的网站请慎用



--------------------------------------------------------------------------



假设在你的应用中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);

        }

}