According to the docs, the query cache works properly with OSCache. I'm trying to switch from EHCache to OSCache due to a very difficult to track down bug that I'm encountering. I don't know if it's due to EHCache, or some other factor, so for now, I'm going to try to switch caches to see if the problem goes away.

I'm having trouble using OSCache with the query cache. It seems when I have a query with parameters in it, the cache always returns the result of the first query, regardless of which query parameters I pass to it.

EHCache does not exhibit this behavior.

A quick dig through the L2 cache system shows that Hibernate uses QueryKey as the key to store the caches. While QueryKey does not implement toString, it does have a hashCode implementation which seems incorrect, since it simply returns the hashCode of the SQL query string, which does NOT include parameters of any type. While I haven't dug through OSCache's implementation, I think it's safe to say that it probably uses hash-codes to compare key values and this is why it is failing.

While I can't do it right this moment, I will attempt to see if replacing the hashCode method with a working one will help. I'll attempt to use Apache commons-lang's HashCodeBuilder to build a working hash code.

Yes, you correctly identified the bug. It is fixed now. I was not aware of this nasty behavior of OSCache, and we don't really regularly test with OSCache.

Forgot to say: the bug was already fixed a while ago. In CVS, both branches.

I've been digging around the CVS tree, on the assumption that this fix would be in here. It seems that the fix that you're referring to is actually the implementation of toString() rather than hashCode(). hashCode() is still broken.

The current v21branch version (1.1.2.6) reads:


I've coded the following replacement method:


The 'magic numbers' 59 and 15 are just two random, non-zero, non-even numbers, as specified in the HashCodeBuilder docs.

This has only been lighty tested, but since it matches all of the fields touched in the QueryKey constructor, it seems solid. It certainly fixes the bug I was referring to and the queries that are supposed to be cached are being properly cached,.

Actually OSCache provider uses toString() to compare keys, so the inefficient (but perfectly correct) hashCode() implementation is irrelevant. Anyway, I just now improved the hashCode() method, to eliminate the inefficiency.

Using 2.1.6 so let me know if I have to build CVS head to get the fix but it does not appear any parameters are part of my query cache keys. For example,
sql__select_this_PAGE_ID_as_PAGE_ID0_,_this_NAME_as_NAME0__from_guilds_admin_PAGES_this_where_1=1_order_by_this_NAME_asc__parameters___net_sf_hibernate_cache_StandardQueryCache.cache

Furthermore, another troubling aspect is that the key is too long to have as a filename for many filesystems. Is there anyway I can override the toString on the query caches?