[ http://issues.apache.org/jira/browse/IBATIS-70?page=comments#action_58944 ] Clinton Begin commented on IBATIS-70: -------------------------------------
Yes, I too have recreated it. This is by far the most critical bug open today. It will be the first one I fix once our SVN repository is set up!!! (Argh!) Luckily, it will only affect those people using Strings or a combination of strings and integers as keys. Practically speaking, it will only affect people using a single string. > 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
