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! It seems to me that 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. Hence my question...is iBatis caching broken, or am I missing something? Thanks for any ideas! Jeff Butler
