hibernate - Standard way to handle Repository in JPA -

consider following scenario.

there table in db content form repository. table updated (updation of existing extities, addtion of new entities or removal of entities) rarely. approach using create singleton xxxrepository pojo read rows (entities) xxx table , store them in map.

if updating xxx table after update part of code executed, post runnable run clear repository (map) , hence next time entity being located map, loadrepository invoked (as map null).

this way handle repository caching can use throught application life cycle.

is there standard way provided/supported in jpa/hibernate achieve/implement requirement.

i went through caching mechanism (both 1st , 2nd level cache). seems entities or queries or data , different purpose/approach expected happening or achieved repository. if able achieve somehow using 2nd level cache, there 1 more issue cache updates in case of jpa operations , jpql queries. in case of jdbc or native queries fail updated , have stale data (correct me if i'm wrong).

please me in regards standard way followed in jpa this.

if entities can held in memory without problem, problem solved second level cache. each time want read data several of these entities, have execute request fetching entities, , filter results in java.

if unique "fetch all" request cached in second level cache, return entities memory, except if update executed (in case second level cache throw away cached values). should put entities in second level cache, , make sure cache entity able hold entities. way, session.get calls , navigation through relationships entity use second level cache.

in clear, have reimplemented second level cache you.

whatever solution is, it's not possible avoid returning stale data if process updates data behind hibernate's back. either accept fact (and tune time live of cache in order limit stalenesss), or don't accept , have no other choice querying database each time need data.