ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: CacheKey collision frequency
Date Thu, 24 Mar 2005 23:12:54 GMT
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