the default cache setting for objects is called entity :
The cache configuration may vary for each type of data stored in the cache. To override the cache configuration template, use the hibernate.cache.infinispan.data-type.cfg , where data-type can be one of:
entity Objects indexed by the @Id or @EmbeddedId .
immutable-entity Objects marked with the @Immutable annotation or set to mutable=false in the mapping file.
naturalid Objects indexed by their @NaturalId attribute.
collection All collections.
timestamps Type of mapping object → timestamp of the last modification. Used to cache requests.
query Match a query -> query result.
pending-puts Helper caches for regions that use cache invalid mode.
By default, collection , immutable-entity and naturalid also configured for entity , so you do not need to configure them separately (unless you want, of course, separate configurations), as you can see in the documentation and the source code .
Note
In general, creating a distributed Hibernate L2 cache may not be a good idea, since object instances are stored in a disassembled hydrated state in L2, which means that only the identifiers of related objects are stored together with the state of the parent object.
Suppose you have the following objects ( A , B , C all cachable):
@Entity public class A { @ManyToOne private B b; @OneToMany private Collection<C> cs; }
Even if the cs collection was also cachable to completely collect the entity A instance from the cache, you would have the following network crawls to other cluster nodes:
- Get Object
A - Get object
B based on the identifier stored in association B - Get a collection of
cs identifiers. - For each identifier in the
cs collection, select the state of the C object one by one.
Obviously, if you collect a collection of instances of A (for example, from a query result), all this is done for each instance of A
All this implies that reading data from the database directly (with correctly configured lazy loading using batch size , for example) can be much more efficient than all network round trips in a distributed cache.
In addition, one of the reasons why the entity / collection cache should be executed in cluster invalidation mode (data is cached only on a node that reads / writes it, but is invalid on other nodes when changing).