iBatis Caching Should Not Rely on hashCode Alone
------------------------------------------------
Key: IBATIS-70
URL: http://issues.apache.org/jira/browse/IBATIS-70
Project: iBatis for Java
Type: Bug
Components: SQL Maps
Environment: All
Reporter: Jeff Butler
Priority: Critical
(From the mailing list)
I found a problem recently related to iBatis caching.
I have a mapped select statement that takes one parameter, a string.
I'm not using a parameter map, just passing the string in directly on a
queryForList() call. I was using the LRU cache on that statement. I
found that the statement was returning incorrect values in several
cases. It came down to this...two parameter strings yielded the same
hashCode, so iBatis caching thought they were the same string and
incorrectly returned the value from the cache.
An example is the two strings "HS1CS001" and "HS1D4001". Both strings
yield the same hashCode. So the com.ibatis.sqlmap.engine.cache.CacheKey
class generated the same CacheKey for two different calls. If the
statement has already been called with "HS1CS001" as the parameter, and
is later called with "HS1D4001", then the result for the first call will
be returned from the cache on the second call. Not good!
So, iBatis should not rely on hashCode to generate its
internal CacheKey since it is certainly allowable for different, and
unequal, objects to return the same hashCode.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
