I have a website that allows searches for lists of content in various ways, for instance "show stuff created by user 523 ordered by date" or "show a list of the most recent 10 posts."

I use Hibernate for my ORM, and Hibernate provides a cache for objects. For lists of objects, though, like the front page list of most recent content, I'm at a loss as how best to cache that content. Right now, I have my Spring controllers just return a standard JSP page, and then I use oscache at the JSP level wrapped around a call to another class.

This seems inelegant, though. What I really want is for my controller to have access to a cached result if one's available so that the JSP can just be concerned with displaying results.

Not exactly. Query caching seems neat, but also limited and prone to frequent flushing in many situations. I was hoping for some way to cache arbitrary calls to the DAO more generically, but I'm sure that's exactly what I want. I'm just sort of wondering if there are any standard techniques out there I'm not aware of. For instance, what might stack overflow use to render its front page, or does every visit trigger a database read?
–
Brandon YarbroughOct 19 '09 at 7:54

I think you may be doing query caching a disservice, I haven't found it to be limited, and and its flushing too often then it needs tuning and configuration, like any caching technology.
–
skaffmanOct 19 '09 at 7:55

The list of ids that correspond to the query : this result is subject to change in many ways. For example, if any of the tables used by the query is changed, the result could be changed. Whether or not it is effectively changed would be difficult to compute and maintain up to date, so it is inefficient in most cases. So Hibernate chooses not to cache the ids that correspond to a query.

Once a list of ids corresponding to a query is known, there is also the need for all data corresponding to the entities returned, plus all entities (or components) that are fetched. Here we suppose that you decided that these entities are constant-enough and read enough that caching them is advisable. This data retrieval benefits fully from the regular second-level Hibernate cache.

For caching efficiency and code simplicity, I split such results I want to cache in two levels :

a query returning only the ids (plus possibly entities fetched that were not chosen for the second-level Hibernate cache)