anchor.diff:  }
   --
   
  -Queries executed regularly that return the same results can also benefit from second-level caching.
  -In the absence of updates to entities involved in a query, cached query results can be immediately returned to the caller.
  -To cache a query, mark it as cacheable:
  +Queries can also benefit from second-level caching. Cached query results can be returned immediately to the caller, avoiding to run the query on the database.
  +
  +Be careful as this implies the results might not reflect recent changes.
  +
  +To cache a query, mark it as cacheable on the `Query` instance:
   
   [source,java]
   --
  
positive.code: }
  --
  
  When an entity is annotated with `@Cache`, all its fields are cached except for collections.
  Entity collections need to be individually annotated to be cached:
  
  [source,java]
  --
  
negative.code: --
  
  By default entities are cached in regions named after their fully qualified name, e.g. `com.acme.Country`.
  
  Collections are cached in regions named after the fully qualified name of their owner entity and collection field name, separated by `#` character, e.g. `com.acme.Country#cities`.
  
  All cached queries are by default kept in a single region dedicated to them called `default-query-results-region`.
  
  All regions are bounded by size and time by default. The defaults are `10000` max entries, and `100` seconds as maximum idle time.
  
  The size of each region can be customized via the `hibernate.cache.<region_name>.memory.object.count` property (Replace _<region_name>_ with the actual region name).
  
  To set the maximum idle time, provide the number of seconds via the `hibernate.cache.<region_name>.expiration.max_idle` property (Replace _<region_name>_ with the actual region name).
  
  [NOTE]
  --
  These caches are kept locally, so they are not invalidated or updated when changes are made to the persistent store by other applications.
  
  Also, when running multiple copies of the same application (in a cluster, for example on Kubernetes/OpenShift), caches in separate copies of the application aren't synchronized.
  
  For these reasons, enabling caching is only suitable when certain assumptions can be made: we strongly recommend that only entities, collections and queries which never change are cached. Or at most, that when indeed such an entity is mutated and allowed to be read out of date (stale) this has no impact on the expectations of the application.
  
  Following this advice guarantees applications get the best performance out of the second-level cache and yet avoid unexpected behaviour.
  
  On top of immutable data, in certain contexts it might be acceptable to enable caching also on mutable data; this could be a necessary tradeoff on selected
   entities which are read frequently and for which some degree of staleness is acceptable; this " acceptable degree of staleness" can be tuned by setting eviction properties.
   This is however not recommended and should be done with extreme care, as it might
   produce unexpected and unforeseen effects on the data.
  
  Rather than enabling caching on mutable data, ideally a better solution would be to use a clustered cache; however at this time {project-name} doesn't provide any such implementation: feel free to get in touch and let this need known so that the team can take this into account.
  --
  
  Finally, the second-level cache can be disabled globally by setting `hibernate.cache.use_second_level_cache` to `false`.
  
  When second-level cache is disabled, all cache annotations are ignored and all queries are run ignoring caches; this is generally useful only to diagnose issues.
  