Part 1:
Hibernate does the right thing. The query cache is not per entity. There is a single query cache region, shared by all queries, unless you set a specific region for a query. Each time a table is updated, its timestamp in the timestamps cache is updated. Each time a query is executed, the timestamp of each of the tables where the query searches is compared to the timestamp of the cached result. And of course, the cached result is returned only if itstimestamp is more recent than all the table timestamps.
Part 2:
Yes, it makes sense. The cache for the author remembers that the author with ID 456 has the name “foo” and the birth date 1975/07/19. Only the data stored in the author table is remembered. So, caching the association is also useful: instead of making an additional query to get the set of books of the author when calling author.getBooks(), Hibernate will get the IDs of the books of the author from its cache, and then load each book from the second-level cache. Make sure to cache the Books, though.
Part 3:
I can imagine several reasons:
- there are so many entities and they are so changing that the number of cache hits would be very low, and that the second-level cache handling would in fact consume more time and memory than a solution without cache
- the application is clustered, and the cost and complexity of a distributed second-level cache is too high, for a low gain
- other non-hibernate applications write to the same database, and the cache has thus a big risk of returning stale data, which is not acceptable
- everything goes very well without a second-level cache, and there is no reason to make the application more complex than it is.