Hash stability

Peter Otten __peter__ at web.de
Mon Jan 16 03:18:48 EST 2012

Heiko Wundram wrote:

> Am 15.01.2012 13:22, schrieb Peter Otten:

>> I'm curious: did you actually get false cache hits 

in a suds cache

>> or just slower responses?

> It broke the application using suds, not due to false cache hits, but
> due to not getting a cache hit anymore at all.

> so basically I worked around
> the problem by creating an appropriate cache entry with the appropriate
> name based on hash() using a local copy of xml.dtd I had around. This
> took place on a development machine (32-bit), and when migrating the
> application to a production machine (64-bit), the cache file wasn't used
> anymore (due to the hash not being stable).

Thanks for the explanation.

> if the hash() output is changed. Additionally, if hash() isn't stable
> between runs (the randomized hash() solution which is preferred, and
> would also be my preference), suds caching becomes completely useless.
> And for the results, see above.

I've taken a quick look into the suds source; the good news is that you have 
to change a single method, reader.Reader.mangle(), to fix the problem with 
hash stability. 

However, I didn't see any code to deal with hash collisions at all.

More information about the Python-list mailing list