Some options in the cache configuration can also be overridden directly through properties. These are:. This allows overrides that only affects a particular entity i. Person or collection type i. Infinispan cache provider supports all Hibernate cache strategies: transactional , read-write , nonstrict-read-write and read-only.
Integrations with Hibernate 4. However for all 5. With Hibernate 5. Infinispan provides the same consistency guarantees for both transactional and read-write strategies, use of transactions is considered an implementation detail.
In integrations with Hibernate 5. Also eviction should not be used in this configuration as it can lead to consistency issues. Expiration with reasonably long max-idle times can be used.
In addition to that, the entities must use versioning. This means that this strategy cannot be used for caching natural IDs which are never versioned. This mode mildly relaxes the consistency - between DB commit and end of transaction commit a stale read may occur in another transaction.
However this strategy uses less RPCs and can be more performant than the other ones. Read-only mode is supported in all configurations mentioned above but use of this mode currently does not bring any performance gains. Changing caches to behave different to the default behaviour explained in previous section is explained in the Configuration Properties section.
Hibernate offers a configuration option hibernate. This option checks if the cache contains given key before updating the value from database put-from-load and omits the update if the cached value is already present.
When using invalidation caches it makes sense to keep this off as the put-from-load is local node-only and silently fails if the entry is locked. Adding dependencies Applications running in environments where Infinispan is not default cache provider for Hibernate will need to depend on the correct cache provider version. However, there are alternative ways to which are explained in the Hibernate documentation.
Optionally, queries can also be cached but for that query cache needs to be enabled:. As well as enabling query cache, forcing a query to be cached requires the query to be made cacheable. For example, for JPA queries: query. Deployment scenarios How to configure Infinispan to be the second level cache provider varies slightly depending on the deployment scenario:. Otherwise a clustered configuration is loaded. Single-node standalone Spring application Using Hibernate within Spring applications is a very common use case.
Use Infinispan second level cache provider spring. When running in WildFly, do not set hibernate. Multi-node standalone Spring application If interested in running a Spring application that uses Hibernate and Infinispan as second level cache, the cache needs to be clustered. Configuration reference This section is dedicated at explaining configuration in detail as well as some extra configuration options.
Default local configuration Infinispan second-level cache provider comes with a configuration designed for local, single node, environments. Entities, collections, queries and timestamps are stored in non-transactional local caches. Entities and collections query caches are configured with the following eviction settings:. Eviction wake up interval is 5 seconds. Max number of entries are 10, Max idle time before expiration is seconds. Default eviction algorithm is LRU, least recently used.
Default cluster configuration Infinispan second-level cache provider default configuration is designed for multi-node clustered environments. When data read from the database is put in the cache, with replicated or distributed caches, the data is propagated to other nodes using asynchronous communication. In the presence of concurrent database loads, one operation will succeed while others might fail silently. This has the side effect that under these circumstances, the cache might not be up to date right after making the JPA call that leads to the database load.
However, the cache will eventually contain the data loaded, even if it happens after a short delay. Performing the query is quite expensive. The same query is very likely to be repeatedly executed on different cluster nodes. Defaults to all and can also be non-lazy. A read-only cache is good for data that needs to be read often but not modified.
It is simple, performs well, and is safe to use in a clustered environment. Some applications only rarely need to modify data. This is the case if two transactions are unlikely to try to update the same item simultaneously. In this case, you do not need strict transaction isolation, and a nonstrict-read-write cache might be appropriate.
If the cache is used in a JTA environment, you must specify hibernate. In other environments, ensore that the transaction is complete before you call Session. A read-write cache is appropriate for an application which needs to update data regularly.
Do not use a read-write strategy if you need serializable transaction isolation. In non-JTA environments, be sure the transaction is complete before you call Session. To use the read-write strategy in a clustered environment, the underlying cache implementation must support locking. The build-in cache providers do not support locking.
The transactional cache strategy provides support for transactional cache providers such as JBoss TreeCache. You can only use such a cache in a JTA environment, and you must first specify hibernate. The state of an object is synchronized with the database when you call method flush. To avoid this synchronization, you can remove the object and all collections from the first-level cache with the evict method.
To remove all items from the Session cache, use method Session. The Session provides a contains method to determine if an instance belongs to the session cache.
You can evict the cached state of an instance, entire class, collection instance or entire collection role, using methods of SessionFactory.
The CacheMode controls how a particular session interacts with the second-level cache. After enabling statistics, you can browse the contents of a second-level cache or query cache region. Set hibernate. Optionally, set hibernate. Chapter 6. The query cache 6. Query cache regions 6. Second-level cache providers 6. Configuring your cache providers 6.
Caching strategies 6. Second-level cache providers for Hibernate 6. Managing the cache 6. Moving items into and out of the cache. The query cache. Procedure 6. Enabling the query cache Set the hibernate. This setting creates two new cache regions: org. Query cache regions.
If you are going to enable a second-level cache, you will have to decide, for each persistent class and collection, which cache concurrency strategy to use. Use this strategy if data hardly ever changes and a small likelihood of stale data is not of critical concern.
Use it for reference data only. If we are going to use second-level caching for our Employee class, let us add the mapping element required to tell Hibernate to cache Employee instances using read-write strategy.
Your next step after considering the concurrency strategies, you will use your cache candidate classes to pick a cache provider. Hibernate forces you to choose a single cache provider for the whole application. It can cache in memory or on disk and clustered caching and it supports the optional Hibernate query result cache.
Supports caching to memory and disk in a single JVM with a rich set of expiration policies and query cache support. A cluster cache based on JGroups. It uses clustered invalidation, but doesn't support the Hibernate query cache. A fully transactional replicated clustered cache also based on the JGroups multicast library. It supports replication or invalidation, synchronous or asynchronous communication, and optimistic and pessimistic locking.
The Hibernate query cache is supported. Every cache provider is not compatible with every concurrency strategy. The following compatibility matrix will help you choose an appropriate combination.
You will specify a cache provider in hibernate. Now, you need to specify the properties of the cache regions.
EHCache has its own configuration file, ehcache. A cache configuration in ehcache. That's it, now we have second-level caching enabled for the Employee class and Hibernate, now hits the second-level cache whenever you navigate to an Employee or when you load an Employee by identifier.
0コメント