1. 技术文章
  2. Spring and Hibernate suddenly set the transaction to readonly

Spring and Hibernate suddenly set the transaction to readonly

由 牧云@^-^@ 提交于 2019-11-30 17:44:59

This exception comes from the following code in Spring's HibernateTemplate class:

protected void checkWriteOperationAllowed(Session session) throws InvalidDataAccessApiUsageException {
    if (isCheckWriteOperations() && getFlushMode() != FLUSH_EAGER &&
            session.getFlushMode().lessThan(FlushMode.COMMIT)) {
        throw new InvalidDataAccessApiUsageException(
                "Write operations are not allowed in read-only mode (FlushMode.NEVER/MANUAL): "+
                "Turn your Session into FlushMode.COMMIT/AUTO or remove 'readOnly' marker from transaction definition.");
    }
}

The rationale for this check is explained as:

This is a new consistency check introduced in Spring 1.1.

Invoking HibernateTemplate's save/update/delete methods on a Spring-managed Session in FlushMode.NEVER is potentially dangerous: It means that you are:

  • either doing this in a Spring-managed read-only transaction, which will never flush the Hibernate Session, i.e. never flush your save/update/delete calls. The new check makes you aware that you won't persist your changes in that situation.

  • or working with some other thread-bound Session in FlushMode.NEVER, for example the OpenSessionInViewFilter. If you're overriding closeSession there to flush after view rendering, you should override getSession too, setting the Session to FlushMode.AUTO.

I strongly recommend against the latter, though. If you're using OpenSessionInViewFilter, combine it with middle tier transactions rather than let the filter flush at request completion.

Does any of this ring a bell?

It is possible that there is some bug in the your code or in Spring ORM. To disable this check you can call setCheckWriteOperations(false).

aseesing, i check your configuration. in spring context part, you use

<!-- other methods use the default transaction settings (see below) -->
   <tx:method name="*" read-only="true" propagation="REQUIRED" />

usually, only some accesses are read-only types, such as get/find/query, etc. i suggest use

<!--default is required transaction-->
<tx:method name="*"/>

another thing is, do you use opensessioninview pattern? flush mode could be set in opensessioninview properly. you can use filter in web.xml or use spring interceptor in application context config.

nabil

in your web.xml put :

<filter>
    <filter-name>openSessionInViewFilter</filter-name>
    <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
    <init-param>
        <param-name>flushMode</param-name>
        <param-value>AUTO</param-value>
    </init-param>
</filter>

My guess would be that it is Spring that does this for you. I seem to remember this being done by the OpenSessionInViewFilter in Spring. Are you using that?

This is from memory so it's not very detailed. There are two ways of setting the flushmode. I think a Spring way and a Hibernate way. Because we were using the (Spring?) way only once and the Hibernate way all the other times it made the internal state of Hibernate wrong somehow. Which created my problems. When we made everything consistent the problem went away.

I encountered this when 2 "baseTransactionProxy" were used from 1 bean :

First : 

<bean id="generalDao" parent="baseTransactionProxy">
    <property name="target">
        <bean class="com...GeneralDao" parent="baseDAO" />
    </property>
</bean>

Second : 

<bean id="ruleDao" parent="baseTransactionProxy">
    <property name="target">
        <bean class="com...RuleDao" parent="baseDAO">
            <constructor-arg ref="generalDao"></constructor-arg>
        </bean>
    </property>
</bean>

and we did

class ruleDao{
    generalDao.generalSaveOrUpdateAll(hbms); // OK HERE
    saveOrUpdateAll(otherHbms); //Exception here
}

Not sure if it helps, but it seems that its not good to mix 2 different "baseTransactionProxy" at the same proxy call...

Because you are using an execution pointcut on the implementation and you are utilizing a generic DAO, perhaps this is not handling transactions as you would expect and this is just a manifestation of the real issue.

Please ensure that Spring is proxying your DAO as you expect on that call. You may need to use the target(beanid) syntax to enable the proper transactions for your generic DAO.

标签
java
hibernate
Spring
jboss
spring-transactions
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!