jOOQ and Caching?

Question

I am considering moving from Hibernate to jOOQ but I am not sure if I can do without caching. Hibernate has a first- and second-level cache. I know that jOOQ does have support for reusing prepared statements.

Will I have to take care of caching on my own if I use jOOQ?

Answer 1

Query caching / result caching:

I'm mentioning this, because this kind of cache is also possible with Hibernate, and it might make sense under certain circumstances.

In Hibernate, the query cache works closely with the second-level cache. In jOOQ, you can implement a query cache that intercepts all queries using the jOOQ VisitListener API. There are some blog articles about this topic:

• Hack up a Simple JDBC ResultSet Cache Using jOOQ’s MockDataProvider
• Caching in Java with JOOQ and Redis

There will be better support for this type of cache in the future (not in jOOQ 3.7, yet), as this kind of cache belongs in a SQL API. Note that your JDBC driver might also support this kind of cache already - e.g. ojdbc does.

First-level caching:

The idea behind Hibernate's first level cache doesn't make sense with a more SQL-oriented API like jOOQ. SQL is a highly complex language that works between the actually persisted entities, and your client representation of the same entities. This means that once you use SQL, you will probably create ad-hoc tuples that have nothing to do with the original entity representation of your data.

In other words: First-level caching is a thing that is only possible if you limit the functionality and scope of your query language, and if you take control over ALL your database interactions, the way Hibernate does it. jOOQ expressly doesn't do that.

Second-level caching:

The second-level cache in Hibernate is a cache that is mostly useful with master data and similar types of data where fetching the data from the database hardly ever makes sense, as the data doesn't change.

There is no reason at all, why an ORM should implement this kind of cache, short of convenience in simple cases. But in many cases, you're better off annotating a service method with @Cacheable, e.g. as documented here on this Spring page. This would be a cache on a higher layer than on the ORM / query layer, where you will be able to correlate caching much more tightly with your business logic.