[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3006) ConcurrentModificationException in AbstractBatcher results in infinite loop

ConcurrentModificationException in AbstractBatcher results in infinite loop --------------------------------------------------------------------------- Key: HHH-3006 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3006 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5.ga MySQL 5.0.42 Reporter: Stefan Hauk Assignee: Steve Ebersole Priority: Minor Fix For: 3.2.7, 3.3.0.CR2 Attachments: batcherinfinitelooptest.zip, batcherinfinitelooptest.zip Here is a piece of code from org.hibernate.jdbc.AbstractBatcher's closeStatements() method: Iterator iter = resultSetsToClose.iterator(); while ( iter.hasNext() ) { try { logCloseResults(); ( (ResultSet) iter.next() ).close(); } catch (SQLException e) { // no big deal log.warn("Could not close a JDBC result set", e); } catch (Throwable e) { // sybase driver (jConnect) throwing NPE here in certain cases log.warn("Could not close a JDBC result set", e); } } resultSetsToClose.clear(); In case there is a ConcurrentModificationException thrown when iterating over the resultSetsToClose HashSet the exception will be caught by the catch(Throwable) clause. However, the iteration may continue infinitely because of the corrupted HashSet. This pegs one CPU and logs the following stack trace over and over again: 28/11 20:16:50 WARN AbstractBatcher [resin-tcp-connection-myserver:6001-15] Could not close a JDBC result set java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841) at java.util.HashMap$KeyIterator.next(HashMap.java:877) at org.hibernate.jdbc.AbstractBatcher.closeStatements(AbstractBatcher.java:314) at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:382) at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:324) at org.hibernate.impl.SessionImpl.close(SessionImpl.java:298) at org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:774) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.closeSession(OpenSessionInViewFilter.java:252) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:183) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75) at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:70) at com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:188) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:178) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:229) at com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:419) at com.caucho.server.port.TcpConnection.run(TcpConnection.java:389) at com.caucho.util.ThreadPool.runTasks(ThreadPool.java:492) at com.caucho.util.ThreadPool.run(ThreadPool.java:425) at java.lang.Thread.run(Thread.java:595) The catch(Throwable) block was added in Hibernate 3.2.3 if I saw that correctly. Apparently the reason was to catch a NPE thrown by a sybase driver here, but catching Throwable catches more than that and produces this side-effect. Now I do realize that the ConcurrentModificationException might be caused by not using Hibernate in a correct way, but I haven't determined the cause for it yet. However, I do think that Hibernate should fail more gracefully than it currently does.