Return-Path: Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 36599 invoked by uid 99); 9 Feb 2005 15:25:55 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from mail.cstone.dhs.state.il.us (HELO mail.cstone.dhs.state.il.us) (163.191.134.137) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 09 Feb 2005 07:25:55 -0800 Received: from DCSTONE1-MTA by mail.cstone.dhs.state.il.us with Novell_GroupWise; Wed, 09 Feb 2005 09:25:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 09 Feb 2005 09:25:13 -0600 From: "Jeff Butler" To: Subject: Re: Is iBatis Caching Broken??? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked Done (IBATIS-70). Thanks for the quick response! Jeff >>> clinton.begin@gmail.com 2/9/2005 9:13:51 AM >>> Hi Jeff, You're absolutely right....but I thought this is what it did....after all, we just use HashMaps (which handles collisions) as the underlying implementation. When the developer's intention is not equal to the application behaviour, that is generally indicative of a bug. :-) ...and I believe I've found it....at some point the strong equals() implementation of CacheKey was removed. Nasty. :-( Could you submit a JIRA request for this and we'll make sure it's fixed in the next release? Clinton On Wed, 09 Feb 2005 09:02:37 -0600, Jeff Butler wrote: > 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 > >