To indicate that an item can be found in a specific branch, a new table was created, items_location (having an id, an item_id (the item placed in the branch), store_id (the branch where the item is placed)).There cannot be an electronic store without a logo, so here we have: The project uses Postgre SQL database, is implemented using Spring Framework and uses embedded Jetty as a web server. A new database was configured as in following tutorial; then, the tables were created using this script.
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.
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.
A demo application was created for illustrating the concepts described in this article.
The demo application, named Electronic Store, manages an electronic store.
In Java world, since there are many libraries for cache, an standardization effort was made, that resulted in JSR 107, or JCache, specification.
Since Hibernate 5.2.0, there is available a new Hibernate module, hibernate-jcache, for integrating a JCache provider as a second-level cache.
Items to be sold are saved in the items table (having an id, serial number, name, description).
Each item can have a review, saved in the reviews table (which id, item_id (item for which the review is created), nr_stars, comment).
While the first level cache is implemented by Hibernate internally, the second level cache is optional, and is provided by a different solution.