ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Shea" <js...@traq.com>
Subject RE: CacheKey collision frequency
Date Mon, 04 Apr 2005 13:52:23 GMT
I guess my larger question then is, why does the design use hash values
as cache key at all? Why not just concatenate the SQL and the parameters
into a big long String and use that as a cache key? 

In theory, including the "checksum" and "count" fields in
CacheKey.equals() gives you 128 bits to work with and that should be
sufficient. But I wonder how well-distributed those latter values
actually turn out to be.

Thanks,
Jim 

-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Thursday, March 24, 2005 5:13 PM
To: ibatis-user-java@incubator.apache.org
Subject: Re: CacheKey collision frequency


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 <jshea@traq.com> 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 
> 
> 
> 
>  
>

Mime
View raw message