[jira] Closed: (IBATIS-70) iBatis Caching Should Not Rely on hashCode Alone

["Clinton Begin (JIRA)" <ib...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/IBATIS-70?page=history ]
     
Clinton Begin closed IBATIS-70:
-------------------------------

      Assign To: Clinton Begin
     Resolution: Fixed
    Fix Version: 2.0.9b


Fixed.  All parameters are now compared using .equals(), but only if previous, faster equality checks hold true.

> 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
>     Assignee: Clinton Begin
>     Priority: Critical
>      Fix For: 2.0.9b

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