Query Caching / Caching Results:
I mention this because this kind of cache is also possible with Hibernate , and this may make sense under certain circumstances.
In Hibernate, the query cache works closely with the second-level cache. In jOOQ, you can implement a request cache that intercepts all requests using the jOOQ VisitListener API. There are several blog articles on this topic:
In the future, support for this type of cache will be improved (but not in jOOQ 3.7), since this kind of cache belongs to the SQL API. Note that your JDBC driver may also support this kind of cache already - for example. ojdbc does.
First level caching:
The idea of Hibernate Level 1 Cache makes no sense with a more SQL-oriented API such as jOOQ. SQL is a very complex language that works between actually stored entities and your client representation of the same object. This means that after using SQL, you are likely to create ad-hoc tuples that have nothing to do with the original representation of the essence of your data.
In other words: caching at the first level is a thing that is possible only if you limit the functionality and scope of your query language, and if you take control of all your interactions with the database, how Hibernate does it. jOOQ does not explicitly do this.
Second level caching:
Hibernate's second-level cache is a cache that is mostly useful with basic data and similar data types, where retrieving data from a database almost never makes sense, because the data does not change.
There is no reason why ORM should implement this type of cache, apart from convenience in simple cases. But in many cases, you'd better annotate the service method with @Cacheable , for example. as described here on this Spring page . This will be a cache at a higher level than at the ORM / query level, where you can more accurately associate caching with your business logic.
Lukas Eder
source share