We have production code running for some time now. Yesterday, we suddenly received the following error:

2008-05-19 09:17:03,901 ERROR [org.hibernate.AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: scrollable result sets are not enabled
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:475)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:423)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547)
at org.hibernate.loader.Loader.scroll(Loader.java:2285)
at org.hibernate.loader.criteria.CriteriaLoader.scroll(CriteriaLoader.java:89)
at org.hibernate.impl.SessionImpl.scroll(SessionImpl.java:1533)
at org.hibernate.impl.CriteriaImpl.scroll(CriteriaImpl.java:297)

We use a slight modified version of paginationCode (http://www.hibernate.org/248.html) with Criteria instead of query

The issue went away after we restarted Tomcat (5.0.28).

Using Hibernate version: 3.2.6ga with the following properties:

<property name="dialect">org.hibernate.dialect.Oracle10gDialect</property>
<property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
<property name="org.hibernate.cache.CacheProvider">
net.sf.ehcache.hibernate.EhCacheProvider
</property>
<property name="hibernate.cache.use_second_level_cache">false</property>
<property name="hibernate.cache.use_query_cache">false</property>
<property name="current_session_context_class">thread</property>
<property name="bytecode.use_reflection_optimizer">true</property>

Because this rarely happens and we aren't unable to recreate the problem, we would like community feedback on what to watch out for in preventing the problem from reappearing. Thanks.

Just recently hacing the same issue, has anyone figured out the cause? Restarting the server can fix the issue ... or bring it back. How does hibernate check for support for scrollable result sets? Could it be a timing issue with the database? Could c3p0 be to blame?

We're using Hibernate with PostgreSQL and a c3p0 connection pool.

Looking at the code, it seems likely that if hibernate fails to connect to the database during startup, or the JDBC driver doesn't have enough information to answer its questions about capabilities, the support for scrollable result sets would default to "off".

It looks like setting `hibernate.jdbc.use_scrollable_resultset = true` might prevent this error.

See `org.hibernate.cfg.SettingsFactory.buildSettings(Properties)`.

I do think, however, that if hibernate is relying on a database connection to gather this critical data, it should not fail quietly if the database is not present, as it may result in a less reliable server in case things are being restarted automatically.

Hibernate does not fail quietly if it cannot connect to the database. However, scrollable results are an optional feature, so it's fine to create a connection without enabling them, as long as you won't use them.
The bug if any is that it produces (in this very old version) an Assertion Error, it would likely be easier to understand as configuration error.

Yes, setting hibernate.jdbc.use_scrollable_resultset to true does solve this problem. Thanks a lot.

My specific use case was on a server which when rebooted:
1) mysql reports started
2) tomcat starts (service depends on mysql)
3) mysql detects:

4) tomcat starts application which on startup attempts to connect to the database but cannot get connection, so I get:

5) mysql finishes recovery after half a minute and reports: ready for connections
6) c3p0 managed connection from my application finally gets a connection and application runs correctly apart when it needs to do a scrollable query where I get the:


Setting this option to true makes my application start with:

no matter whether a datasource is available or not.