此内容没有您所选择的语言版本。
Chapter 3. Local Caches
While Data Grid is particularly interesting in clustered mode, it also offers a very capable local mode. In this mode, it acts as a simple, in-memory data cache similar to a ConcurrentHashMap.
But why would one use a local cache rather than a map? Caches offer a lot of features over and above a simple map, including write-through and write-behind to a persistent store, eviction of entries to prevent running out of memory, and expiration.
Data Grid’s Cache interface extends JDK’s ConcurrentMap — making migration from a map to Data Grid trivial.
Data Grid caches also support transactions, either integrating with an existing transaction manager or running a separate one. Local caches transactions have two choices:
-
When to lock? Pessimistic locking locks keys on a write operation or when the user calls
AdvancedCache.lock(keys)explicitly. Optimistic locking only locks keys during the transaction commit, and instead it throws aWriteSkewCheckExceptionat commit time, if another transaction modified the same keys after the current transaction read them. - Isolation level. We support read-committed and repeatable read.
3.1. Simple Caches
Traditional local caches use the same architecture as clustered caches, i.e. they use the interceptor stack. That way a lot of the implementation can be reused. However, if the advanced features are not needed and performance is more important, the interceptor stack can be stripped away and simple cache can be used.
So, which features are stripped away? From the configuration perspective, simple cache does not support:
- transactions and invocation batching
- persistence (cache stores and loaders)
- custom interceptors (there’s no interceptor stack!)
- indexing
- transcoding
- store as binary (which is hardly useful for local caches)
From the API perspective these features throw an exception:
- adding custom interceptors
- Distributed Executors Framework
So, what’s left?
- basic map-like API
- cache listeners (local ones)
- expiration
- eviction
- security
- JMX access
statistics (though for max performance it is recommended to switch this off using statistics-available=false)
- Declarative configuration
<local-cache name="mySimpleCache" simple-cache="true"> <!-- expiration, eviction, security... --> </local-cache>- Programmatic configuration
DefaultCacheManager cm = getCacheManager(); ConfigurationBuilder builder = new ConfigurationBuilder().simpleCache(true); cm.defineConfiguration("mySimpleCache", builder.build()); Cache cache = cm.getCache("mySimpleCache");
Simple cache checks against features it does not support, if you configure it to use e.g. transactions, configuration validation will throw an exception.
