The Perils of GetHashCode
Recently I ran into some unexpected, and rather strange, issues on an application server using the Enterprise Library 2.0 Cache Application Block. Apparently there were occurring some strange collisions while retrieving the data from CacheData (the table where the cached data is stored) where the same cache key was having multiple entries, something the Dictionary container where the data is stored isn’t too happy about. The guys at Patterns and Practices, for performance issues, don’t use the cache key as a primary key for that table, but a much more efficient and more easily “indexable” integer, which, in this case, is being calculated using the GetHashCode of the cache key. Usually the GetHashCodeimplementation isn’t a fully blown hash algorithm (unlike the more robust MD5 or SHA) so I allways doubted of the uniqueness, particularly in this case where the application server was moved from a 32 bit to a 64 bit architecture, nothing a quick trip do the good old MSDN wouldn’t confirm:
Remarks
The behavior of GetHashCode is dependent on its implementation, which might change from one version of the common language runtime to another. A reason why this might happen is to improve the performance of GetHashCode.
This basically means you shouldn’t trust GetHashCode, because the result for a given string can, and surely will, be different depending where you are calculating it, namely between 32 and 64 bit architectures. The main lesson to be learnt here is GetHashCode, either for String or any other type, should only be used for disambiguation of entities in runtime.
Paulo Morgado said:
Have you reported it?
22 hours after the fact.http://www.codeplex.com/entlib/WorkItem/List.aspx