[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2470) Use of session.createSQLQuery causes memory leak
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470?page=c...
]
Gail Badner commented on HHH-2470:
----------------------------------
HHH-2470.patch only defines equals() and hashCode() for NativeSQLQueryScalarReturn and
NativeSQLQueryNonScalarReturn.
I see that NativeSQLQueryNonScalarReturn.equals(Object obj) method ensures that objects
that are equal are of the same class.
Subclasses of NativeSQLQueryNonScalarReturn do not override equals(), so there are no
checks for equality on subclass-specific data.
It seems that the fix in HHH-2470.patch would allow two objects of the same subclass to be
equal, when they really are not equal.
For example, suppose 2 NativeSQLQueryCollectionReturn objects are equal, except their
ownerEntityName or ownerProperty is different. The patch would make these objects equal.
NativeSQLQueryNonScalarReturn.determineHashCode() does not take the objects' class
into account and subclasses do not override hashCode().
Wouldn't this allow objects of the same subclass with different subclass-specific
data, or even objects of different subclasses, to have the same hash code?
Could these situations come up in practice?
Am I missing something here?
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
Fix For: 3.5.x
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira