There was a bug between 2.0.0 and 2.0.9. It's fixed in the current release. The hashing algorithm is nothing special and not unlike that used by Apache commons and others.
Hence, the hashing algorithm is not the problem. The problem is that it's a 32 bit space, which is ridiculously small to depend on. So now the cache key uses the original values for the equals() implementation. Cheers, Clinton On Tue, 22 Mar 2005 16:28:20 -0600, Jim Shea <[EMAIL PROTECTED]> wrote: > > Clinton, et al: > > I ran into an issue today which turned out to be caused by a CacheKey > collision using version 2.0.0. Basically, the arguments to the statement in > question were two small integers and so the CacheKeys turned out not to be > very well-distributed. > > The CacheKey.update() method in 2.0.9 (which is what is going in with the > next version of our app) appears to differ slightly and doesn't display the > pathological behavior for the specific arguments which I tested. What I was > wondering, however, is > > 1) if you'd done any experiments to convince yourselves of the robustness of > the hashing algorithm > 2) if you've ever considered making CacheKey generation pluggable, so that > applications that needed to could make appropriate tradeoffs of speed vs. > accuracy. > > IBATIS continues to be a joy to work with. Keep up the good work! > > Jim > > > > _________________ > > james conrad shea > senior developer > traq-wireless, inc. > desk: 512.344.0185 > cell: 512.415.8724 > fax: 512.345.0945 > web: www.traq.com > > > > >
