[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27160 ] 

Steve Ebersole commented on HHH-2631:
-------------------------------------

The basic (simplified) idea of a "load context" is contextual scoping of information relating to the processing of a result set.  In an ideal scenario, I'd actually have each entry in the two main maps available *as part of the result-set*; then when a result-set closes, it can make sure these entries get cleaned up.  Long term that may actually be an option; nested loader stacks make it "interesting"...

But for now, given the current codebase, the desire would be to release these resources as the result sets are being closed as a way to approximate the above discussion.  There are two main candidates:
1) as part of the specific Loader methods controlling the result sets (doQuery, sequentialLoad, etc)
2) as part of the Batcher code.

I'm not a big fan of #2 (I'm not really a big fan of the current batchers at all), but mention it because it would give that "central point" to do this processing provider all the pertinent loader calls are using the Batcher correctly.  My plan, then, is to investigate #1...

And Gail, to answer your specific question, I think calling cleanup on session closing is a great fail-safe.

> Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-2631
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
>             Project: Hibernate3
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.2.4
>         Environment: hibernate 3.2.3 with patch from HHH-2553
>            Reporter: Douglas A. Herrick
>            Assignee: Steve Ebersole
>             Fix For: 3.2.5, 3.3
>
>         Attachments: HHH-2631.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira