Invalidating space timestamp
To configure Hibernate to use second-level cache, we just have to set several properties: Query caches are useful for queries that are frequently executed with the same parameter values, and for entities that are in general unchanged.
Our example is a perfect one for query caches: we are searching for branches by city; this search is quite frequently used, and the probability to search all stores in a given city, by different requests, is quite big.
Also, we introduce new branches, or change their address, very seldom.
Once a store query was cached, it will be invalidated each time we add or update a store.
I’s a REST API, retrieving data from the following database: The database models an electronic store.
The store has several branches, saved in the stores table (which id, city, address).
Jetty was used in embedded mode, and the build produces a file; it can be easily run. As you can see in the repository, we have several controllers.
We have a controller that saves items, updates items or retrieves them by id.
The demo application, named Electronic Store, manages an electronic store.Of course, some optimisations are possible, which send us to the subject of Hibernate caching.Hibernate supports several levels of caching: first level cache (enabled by default), second level cache, query cache (same as first level cache).To improve performance, the second level cache concept was born.
To use second-level cache, we must configure Hibernate to use second-level cache, and integrate a caching solution.
On top of second level cache, a query cache can be added.