In Hibernate 2.1.2 QueryKey.hashCode() there is a comment about the method being "very inefficient".

I want to cache a few hundred queries that vary mostly by value. But because QueryKey.hashCode() only computes hash on the query string and not the values, I'm finding the performance to be much worse than going straight to the database.

My query use case is just complicated enough that I really don't want to hard code a bunch of hash maps or arrays for my data.

As a workaround I downloaded the lastest CVS version of QueryKey.java and TypedValue.java. These versions have a new toString() method. I combine the hash of QueryString.toString() with the original hash code to get a decent key distribution. This is still slow and CPU intensive, but preformance is now very much faster overall than calling my heavily loaded database.

My question is, what progress is being made on QueryKey for efficient, well distributed keys? Will the next release of Hibernate have a new, improved QueryKey.hashCode()?

I would contribute genuine solution myself, but I currently lack the necessary in-depth, comprehensive knowledge of Hibernate source code.

Thanks.

--Jeff

OK, I'll fix it now .... was just laziness on my part.

Actually, if you think about it, its usually not very efficient to cache the same query for many different parameter combinations.

Gavin, thanks for looking into this.

I know the use of the query cache for same query/different params is not optimal.

For my use case, the exact query strings and param count is not known at compile time, only during run time, and even then it can change periodically over time.

The query cache, taken together with all of its configuration and managability aspects, is a very handy tool for dealing with these dynamic situations.


jeff

Has it been fixed? Was looking at the change log, could not tell for sure. Thanks