While diagnosing an apparent resource issue, while running our application for a couple of hours I noticed over time that the number of PreparedStatement and ResultSet instances continued to grow, eventually consuming a fair amount of memory. After digging around a bit, I saw that the entries LoadContext.java inserts into the map named collectionLoadContexts are not removed from the map [method cleanup(ResultSet resultSet) might have removed them, but I never witnessed its invocation, nor did I find any references to it).
I pasted below a stack trace that shows the insertion of elements into collectionLoadContexts:
Thread [http-9943-Processor2] (Suspended (breakpoint at line 53 in CollectionLoadContext))
CollectionLoadContext.<init>(LoadContexts, ResultSet) line: 53
LoadContexts.getCollectionLoadContext(ResultSet) line: 85
BasicCollectionLoader(Loader).handleEmptyCollections(Serializable, Object, SessionImplementor) line: 1060
BasicCollectionLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 690
BasicCollectionLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 236
BasicCollectionLoader(Loader).loadCollection(SessionImplementor, Serializable, Type) line: 1994
BasicCollectionLoader(CollectionLoader).initialize(Serializable, SessionImplementor) line: 36
BasicCollectionPersister(AbstractCollectionPersister).initialize(Serializable, SessionImplementor) line: 565
DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 60
SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1716
PersistentSet(AbstractPersistentCollection).forceInitialization() line: 454
StatefulPersistenceContext.initializeNonLazyCollections() line: 785
QueryLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 241
QueryLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2220
QueryLoader(Loader).listIgnoreQueryCache(SessionImplementor, QueryParameters) line: 2104
QueryLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type) line: 2099
QueryLoader.list(SessionImplementor, QueryParameters) line: 378
QueryTranslatorImpl.list(SessionImplementor, QueryParameters) line: 338
HQLQueryPlan.performList(QueryParameters, SessionImplementor) line: 172
SessionImpl.list(String, QueryParameters) line: 1121
QueryImpl.list() line: 79
HibQuery.list() line: 60
HibRepository(AbstractRepository).query(IQuery, Class) line: 300
While subsequent to this logic, hibernate does close the PreparedStatement and ResultSet instances, since it never removes them from collectionLoadContexts map, those instances are never GCed. After running our application for a couple of days the amount of storage attributed to this potential leak is significant.
hibernate 3.2.3 with patch from
I've upgraded to version 3.2.5 GA, and I've come to realize this patch has been included. My question is, why should the cleanup process perform logging at WARN level? Our logs need WARN, and these are filling up our logs. Any chance this could be changed to an INFO?
Use categories to filter
We are unable to reproduce the warn logging on cleanup. Create a Enhancement Request for lowering the log level with a test case reproducing this behavior...
We're seeing the same excessive logging after upgrading to Hibernate 3.2.5. When you say you're unable to reproduce it does that mean that you never have any CollectionLoadContext objects to clear when cleaning up (line 108 of org.hibernate.engine.loading.LoadContexts) ?
We were able to reproduce this issue. It was fixed in HHH-2795. Please see that ticket for more information.