在没有使用Spring提供的Open Session In View情况下,因需要在service(or Dao)层里把session关闭,所以lazy loading 为true的话,要在应用层内把关系集合都初始化,如 company.getEmployees(),否则Hibernate抛session already closed Exception; Open Session In View提供了一种简便的方法,较好地解决了lazy loading问题.
它有两种配置方式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是个双刃剑,放在公网上内容多流量大的网站请慎用。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
最近在配置 Structs, Spring 和Hibernate整合的问题:
开启OpenSessionInViewFilter来阻止延迟加载的错误的时候抛出了这个异常:
org.springframework.dao.InvalidDataAccessApiUsageException错误
但是在我们开启OpenSessionInViewFilter这个过滤器的时候FlushMode就已经被默认设置为了MANUAL!
如果FlushMode是MANUAL或NEVEL,在操作过程中 hibernate会将事务设置为readonly,所以在增加、删除或修改操作过程中会出现如下错误:
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;
解决办法1:
直接修改OpenSessionInViewFilter过滤器的配置,配置过滤器的时候配置就是在一般的配置里面加上下面蓝色部分就可以了,直接指定flushMode的配置就OK了:
下面是配置文件:(web.xml)
[html] view plaincopyprint?
解决方法2:
就是配置事务的边界,在你方法的执行时配置事务边界!
下面是sessionFactor.xml配置:
[html] view plaincopyprint?
下面是总结:
原理:因为配置openSessionInView时,启动后他默认是给没有配置事务边界的方法都默认为只读的,所以在插入数据时就会报上面的错
相关推荐
### 使用Spring引起的错误:Write operations are not allowed in read-only mode (FlushMode.NEVER) #### 问题背景 在使用Spring框架时,特别是在与Hibernate结合的情况下,可能会遇到“Write operations are not...
`web.xml`配置文件中的`OpenSessionInViewFilter`是为了在HTTP请求的生命周期内保持一个Hibernate的Session,这样可以在视图渲染过程中执行数据库操作,防止“Write operations are not allowed in read-only mode”...
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 ...
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 ...
Windows 98 and ME are not supported in BurnInTest version 5.3 and above. Use a version of BurnInTest prior to 5.2 for compatibility with W98 and ME. Windows 95 and Windows NT =======================...
When True then in ftmPanning mode will be shown only cached image of the initial client area. All parts outside will paints of the TFlexPanel.Brush. When returning from ftmPanning mode the complete ...
Note: You are not allowed to distribute the PRWIN98.INI configuration file if it contains registered user details. However, please feel free to distribute the original, unregistered shareware files, ...
Because device drivers operate at DPC/dispatch level (covered in lesson 2), and page faults are not allowed at this level or above, most device drivers use non-paged pool to assure that they do not ...
Consistency and isolation are the most important in describing SQL Server’s locking model. It is up to the application to define what consistency means, and isolation in some form is needed to ...
Notable changes in Python 3.6.5 What’s New In Python 3.5 Summary – Release highlights New Features PEP 492 - Coroutines with async and await syntax PEP 465 - A dedicated infix operator for matrix...