I've been having an annoying exception a lot lately, and after some research on Google and this forum I still haven't found an answer that could solve my problem.
Here's the thing - sometimes, I get the following error when trying to update or create a new object with hibernate:
org.springframework.dao.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.
at org.springframework.orm.hibernate3.HibernateTemplate.checkWriteOperationAllowed(HibernateTemplate.java:1186)
at org.springframework.orm.hibernate3.HibernateTemplate$12.doInHibernate(HibernateTemplate.java:696)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374)
at org.springframework.orm.hibernate3.HibernateTemplate.save(HibernateTemplate.java:694)
What is really strange is that, sometimes when updating an object with the method getHibernateTemplate().saveOrUpdate(object);
it will work, but sometimes with the same object and by calling the same method it doesn't work, but it seems to depend on how I get the object in the first place.
Example: let's say I have a table with 3 fields: id, type, length. What can happen is that, if I get the object by the id and update the length, then it will work. If I get it by the type and update the length, then it won't work. So what I've been doing so far to avoid the problem is to fetch the object the method that does not cause a problem later, but this is becoming more and more annoying to try and find a way that works.
Also, now I have this exception when trying to create an object (but not all of them, just on one specific table), and can't find a way for a workaround. And I tried to add @Transactional(readOnly = false)
in the transaction but it didn't change anything, and displaying the mode was saying that I wasn't in read-only anyway.
Any suggestions?
Edit 26th of July: here's some configuration related to hibernate
<property name="hibernateProperties">
<props>
<prop key="jdbc.fetch_size">20</prop>
<prop key="jdbc.batch_size">25</prop>
<prop key="cglib.use_reflection_optimizer">true</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
<prop key="connection.autoReconnect">true</prop>
<prop key="connection.autoReconnectForPools">true</prop>
<prop key="connection.is-connection-validation-required">true</prop>
</props>
</property>
also, if it can help
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="execute*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="create*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
</props>
</property>
Edit 31st of August:
The relevant code in my Class that extends HibernateDaoSupport
, to save the objects is:
public void createObject(Object persisObj) {
getHibernateTemplate().save(persisObj);
}
That error message is typically seen when using the Spring OpenSessionInViewFilter and trying to do persistence operations outside of a Spring-managed transaction. The filter sets the session to FlushMode.NEVER/MANUAL (depending on the versions of Spring and Hibernate you're using--they're roughly equivalent). When the Spring transaction mechanism begins a transaction, it changes the flush mode to "COMMIT". After the transaction completes, it sets it back to NEVER/MANUAL, as appropriate. If you're absolutely sure that this isn't happening, then the next most likely culprit is non-thread-safe use of a Session. The Hibernate Session must be used in only one thread. If it crosses over between threads, all kinds of chaos can happen. Note that an entity loaded from Hibernate can hold a reference to the Session in which it was loaded, and handing the entity across threads can thus cause the Session to be accessed from another thread, too.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With