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

Shawn Clowater (JIRA) noreply at atlassian.com
Thu Jun 14 22:00:52 EDT 2007


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

Shawn Clowater commented on HHH-2631:
-------------------------------------

Ok, it looks like someone else found this before I did today, couldn't figure out why my memory was creeping and creeping during a long batch process even though I was clearing the session.

Sanity check, I'm running on 3.2.4 right now and all I did to get around this today was call clear on the hashmaps in LoadContexts when the PersistentContext is cleared.   Should this ghetto rigging cause me any undue grief?  We're about to ship a release out the door and I'd rather not swap the guts out of our hib layer if I don't have to.

Checking the patch code it looks like you're cleaning up each Entity and Collection LoadContext one by one and clearing some internal refs in it which should get me to the same point I think.

> 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, 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

        



More information about the hibernate-issues mailing list