[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_27169 ] 

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

Ok, so here is what I am thinking in terms of implementing:
1) LoadContext already has a cleanup(ResultSet) method; unfortunately it is not used.  Clearly this is something I planned to do, but did not do :(  Anyway, this just needs to get called when we are done processing the given result sets.  The trigger for that should all come from a (a) few finite methods on Loader and (b) the cleanup code in ScrollableResults and IteratorImpl (see discussion #1 below)
2) Add a LoadContext.cleanup() method to be used as the fail-safe.  This new method will be called from SessionImpl on cleaning up the Session.  I do not think we can do this in the transaction completion code because it is possible (depending on the db ) to have result sets span a transaction; the condition I am worried about is iterate() and scroll() queries, which keep the result sets open until explicitly done with.  Anyway, coupled with #1, this really truly should be a fail-safe.  I'll also do some warn logging during that process if there are still associated result-sets

> 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