Turning on hibernate query caching

Sometimes I write a blog post because I want to say something to others, other times because I want to help others, and sometimes I write one for myself.  This is one of the latter type of posts.

I find that nothing drives home a lesson I learned like writing out the solution on my blog, and more than one time I’ve searched my blog because I remember I had written about a topic of current interest in the past.

If you want hibernate, a java ORM tool, to cache your query results, there’s a section in the hibernate manual. Like most of the hibernate documentation, it’s quite good.  One thing that caught me up, though, is that I thought that all queries were cached, as soon as you had set up the correct configuration in your hibernate xml files and marked your objects as cacheable.

However, this is not the case,  as I learned when I turned on the mysql query log and looked at the calls the interesting web application was making.  I did quite a bit of searching, but the answer was in the same section that told me how to set up the configuration (as well as in this forum post).

…most queries do not benefit from caching or their results. So by default, individual queries are not cached even after enabling query caching. To enable results caching for a particular query, call org.hibernate.Query.setCacheable(true).

Doh!  Following these instructions decreased the page load time for some heavy query pages from 8 seconds to 0.5 seconds (the second time the page was loaded).  Impressive indeed, though the production environment might not see such drastic improvements.

One additional note–you can use query caching for SQLQueries (like group operations) by telling hibernate what the type is of each returned value.  If you don’t use addScalar, but you do mark a SQLQuery as cacheable, you’ll get a java.lang.ArrayIndexOutOfBoundsException when that code executes.  More here.

These articles were helpful to me as I navigated Hibernate caching, above and beyond the reference documentation:


Update on GWO for a non profit

Well, after a week or two of data collection, the GWO experiment I had set up for the WILD Foundation caused an issue–apparently it was preventing a javascript shadowbox from working. I didn’t want to get into troubleshooting a javascript component that I had never used on pages I had never seen, so I recommended turning off the experiment to see if that solved the issue.

It did. I knew there was a way to include the GWO javascript just where it was used, on the home page, but I got busy, and by the time I was able to do this, they were hip deep in a website rework. I’ve been involved in website redesigns with too many cooks in the kitchen, so I just asked them to let me know when the dust has settled so I can restart the experiment.

Lessons learned:

  • sometimes volunteer projects take a long time to get to results, and almost definitely will take longer than you plan
  • other opportunities can spring out of volunteering–I showed Emily some space available via another non profit I’m involved in, and she’s looking at possibilities for a fundraiser there.  This never would have happened if I hadn’t volunteered previously
  • the process opened up some ideas for the non profit around changing the home page to highlight things they wanted to focus–sometimes, any perspective from outside an organization is useful

    I’ll let you know when I get a chance to re-enable GWO on the WILD site, but I thought I’d give an update.


    Avoid primitive object wrappers as return values for GWT javascript overlays

    Just a warning, if you build javascript overlay types, you should make sure to only use primitives and strings as primary members of your overlay classes.  I’ve already written about overlay types once before, and here’s the GWT documentation.  If you dig a bit deeper in the GWT documentation, you see this quote:

    JavaScript non-string objects always marshal as JavaScriptObject$

    I was using a java.lang.Double as the return value for one of my overlay objects, and it was fine until I tried to do any math on it.  Nothing would seem to turn the value into a Double or a double, yet no exceptions were thrown.  After some sleuthing in web mode, it turned out that the value returned when I was trying to parse it was NaN, even though when I output it to the screen, the value looked like a double.  I guess it was being treated as a JavaScriptObject$.

    Easily enough fixed, just make sure that you don’t use any objects wrappers of primitives in an overlay type.



    © Moore Consulting, 2003-2017 +