[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2470) Use of session.createSQLQuery causes memory leak

[Harald Wellmann (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32132#action_32132 ] 

Harald Wellmann commented on HHH-2470:
--------------------------------------

I tracked down a heap overflow error in my application to precisely this bug in Hibernate. We are using Hibernate 3.2.6.ga. 

After using a modified version of Hibernate with the patch from attachment hibernate-patch.zip, the problem is gone.

I must admit it is rather scary to see that this showstopper has been known for almost 2 years and a patch has been contributed over a year ago, but the problem still has not been fixed in a release. (I checked that the hashCode() and equals() methods are still missing in the trunk head revision of NativeSQLQueryNonScalarReturn and NativeSQLQueryScalarReturn.)

How many other problems of a similar severity may be lurking around in Hibernate?

> Use of session.createSQLQuery causes memory leak 
> -------------------------------------------------
>
>                 Key: HHH-2470
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470
>             Project: Hibernate Core
>          Issue Type: Patch
>          Components: query-sql
>    Affects Versions: 3.1.3
>         Environment: Win XP, Oracle 10g, Java 1.4.2
>            Reporter: Bjørn Bjerkeli
>            Assignee: Gail Badner
>         Attachments: HHH-2470.patch, hibernate-patch.zip, QueryPlanCacheTest.java, TestCase.zip
>
>
> NativeSQLQuerySpecification fails to properly implement equals and hashcode caused by lacking implementation of hashCode and equals in all SQLQueryReturn implementations and SQLQueryScalarReturn which are members of NativeSQLQuerySpecification. I can see that NativeSQLQuerySpecification has been changed in 3.2, but the problem is still there.
>  
> NativeSQLQuerySpecification instances are used as keys for retrieving and caching NativeSQLQueryPlan instances.
>  
> This causes the caching-mechanism to be pretty useless when Queries created by session.createSQLQuery because new entries will be added all the time in the QueryPlanCache and the SoftLimitMRUCache member.
>  
> So far so good, the more serious problem that is caused by this is stems from the implementation of SoftLimitMRUCache which again uses LRUMap in commons-collection. The put - method of the cache is not treadsafe, and that causes the following fragment in LRUMap to allow the map to grow beyond its maximumSize. That is bacause the containsKey method will return an incorrect result when concurrently updating the map. 
>  
>    public Object put( Object key, Object value ) {
>  
>         int mapSize = size();
>         Object retval = null;
>  
>         if ( mapSize >= maximumSize ) {
>  
>             // don't retire LRU if you are just
>             // updating an existing key
>             if (!containsKey(key)) {
>                 // lets retire the least recently used item in the cache
>                 removeLRU();
>             }
>         }
>  
>         retval = super.put(key,value);
>  
>         return retval;
>     }
>  
> I have included a test-case that demonstrates:
> 1) Wrong implementation of equals and hashCode in NativeSQLQuerySpecification 
> 2) Concurrent use of LRUMap causes the map to grow beyound it's max limit
> 3) Concurrent execution of session.createSQLQuery causes memory leak due to 1) and 2)
>  
> I would be more than happy to contribute to get this fixed. Just let me know.

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