Hibernate version:
My version is 3.0.5, but I just checked the SVN repository for the 3.2 trunk and the same problem exists, so presumably all versions.
Full stack trace of any exception that occurs:
The full stack trace would be entirely pointless in this case - here's the important stuff:
Code:
java.lang.ClassCastException: org.hibernate.cache.QueryKey
at org.hibernate.stat.SecondLevelCacheStatistics.getEntries(SecondLevelCacheStatistics.java:50)
at edu.taylor.domain.person.CachingPersonDirectory.logSecondLevelCacheContents(CachingPersonDirectory.java:22)
at edu.taylor.domain.person.CachingPersonDirectory.getPersonWithBannerId(CachingPersonDirectory.java:30)
at edu.taylor.domain.person.PersonLoadingFactoryBean.getObject(PersonLoadingFactoryBean.java:18)
Reproducing the problemEnable the query cache for your SessionFactory, and then execute a Query something like this:
Code:
Query q = session.createQuery(
"from " + PersonImpl.class.getName() + " p " +
"where p.bannerId = ?");
q.setString(0, bannerId)
.setCacheable(true)
.setCacheRegion("getPerson");
Then try to grab the second-level cache entries for the query's region:
Code:
getSessionFactory()
.getStatistics()
.getSecondLevelCacheStatistics("getPerson")
.getEntries();
And you get a stack trace. Nothing fancy going on here. The offending code:
Code:
public Map getEntries() {
Map map = new HashMap();
Iterator iter = cache.toMap().entrySet().iterator();
while ( iter.hasNext() ) {
Map.Entry me = (Map.Entry) iter.next();
map.put( ( (CacheKey) me.getKey() ).getKey(), me.getValue() );
}
return map;
}
I suspect this was written before there *was* a query cache, when CacheKey was all you'd need to worry about. Such is no longer the case of course - queries use a different class as their key.
Would've posted straight to the JIRA since this issue appears so straight-forward, but as this would be my first submission, and as the entry page to the JIRA is awfully insistent that I'm probably just an idiot and everything is fine, here we are =) I can drum up a little test case that would reproduce the problem if necessary, but it doesn't seem like it would be in this case.
Login
FAQ
Search
