CODEWITHSUNDEEP
hibernatejpa
Yogesh Golande
Yogesh Golande

Reputation: 83

Standard way to handle Repository in JPA

Consider the following scenario.

There is a table in db whose content together form as a repository. This table will be updated (updation of existing extities, addtion of new entities or removal of entities) rarely. So currently the approach that I was using was to create a singleton XXXRepository pojo which will read all the rows (entities) from XXX table and store them in a map.

If someone is updating the XXX table then after the update part of code is executed, a post runnable will run which will clear the repository (map) and hence next time any entity is being located from the map, the loadRepository will be invoked (as the map will be null).

This the way I currently handle repository caching which I can use throught the application life cycle.

Is there any standard way provided/supported in JPA/Hibernate to achieve/implement this requirement.

I went through the caching mechanism (both 1st and 2nd level cache). But it seems to be for entities or queries or data and for different purpose/approach than what is expected to be happening or achieved by Repository. Also if we are able to achieve this somehow by using 2nd level cache, then there is one more issue that cache updates only in case of jpa operations and jpql queries. In case of jdbc or native queries it will fail to be updated and we will have stale data (correct me if I'm wrong).

Please help me in this regards as what is the standard way to be followed in jpa for this.

Upvotes: 0

Views: 320

Answers (1)

JB Nizet
JB Nizet

Reputation: 692181

If all the entities can be held in memory without problem, then the problem is easily solved by the second level cache. Each time you want to read data from several of these entities, you just have to execute the request fetching all the entities, and filter the results in Java.

If this unique "fetch all" request is cached in the second level cache, then it will always return the entities from memory, except if an update is executed (in which case the second level cache will throw away its cached values). You should also put the entities themselves in the second level cache, and make sure the cache for this entity is able to hold all the entities. This way, the session.get calls and the navigation through relationships to this entity will also use the second level cache.

In clear, you have reimplemented what the second level cache does for you.

Whatever the solution is, it's not possible to avoid returning stale data if some process updates the data behind Hibernate's back. Either you accept this fact (and tune the time to live of the cache in order to limit the stalenesss), or you don't accept it and you have no other choice than querying the database each time you need data.

Upvotes: 1

Related Questions