General Ehcache
Can I use Ehcache as a memory cache only?
Yes. Just set the persistence strategy of cache to “none.”
Can I use Ehcache as a disk cache only?
As of Ehcache 2.0, this is not possible. You can set the maxEntriesLocalHeap to 1, but setting the maxSize to 0 now gives an infinite capacity.
Is it thread-safe to modify element values after retrieval from a Cache?
Remember that a value in a cache element is globally accessible from multiple threads. It is inherently not thread-safe to modify the value. It is safer to retrieve a value, delete the cache element, and then reinsert the value. The
UpdatingCacheEntryFactory does work by modifying the contents of values in place in the cache. This is outside of the core of Ehcache and is targeted at high performance CacheEntryFactories for SelfPopulatingCaches.
Can non-Serializable objects be stored in a cache?
As of Ehcache 1.2, they can be stored in caches with MemoryStores. If an attempt is made to replicate or overflow a non-serializable element to disk, the element is removed and a warning is logged.
What is the difference between TTL, TTI, and eternal?
These are three cache attributes that can be used to build an effective eviction configuration. It is advised to test and tune these values to help optimize cache performance. The
timeToIdleSeconds parameter (TTI) is the maximum number of seconds that an element can exist in the cache without being accessed. The
timeToLiveSeconds parameter (TTL) is the maximum number of seconds that an element can exist in the cache whether or not is has been accessed. If the
eternal flag is set, elements are allowed to exist in the cache eternally and none are evicted. The eternal setting overrides any TTI or TTL settings. These attributes are set for the entire cache in the configuration file. If you want to set them per element, you must do it programmatically. For more information, see
Managing Data Life in the
Ehcache Configuration Guide.
What happens when maxEntriesLocalHeap is reached? Are the oldest items expired when new ones come in?
When the maximum number of elements in memory is reached, the Least Recently Used (LRU) element is removed. “Used” in this case means inserted with a put() or accessed with a get(). If the cache is not configured with a persistence strategy, the LRU element is evicted. If the cache is configured for “localTempSwap,” the LRU element is flushed asynchronously to the DiskStore.
Why is there an expiry thread for the DiskStore but not for the MemoryStore?
Because the MemoryStore has a fixed maximum number of elements, it will have a maximum memory use equal to the number of elements multiplied by the average size. When an element is added beyond the maximum size, the LRU element gets pushed into the DiskStore. While we could have an expiry thread to expire elements periodically, it is far more efficient to only check when we need to. The tradeoff is higher average memory use. The expiry thread keeps the DiskStore clean. There is less contention for the DiskStore's locks, because commonly used values are in the MemoryStore. We mount our DiskStore on Linux using RAMFS, so it is using OS memory. While we have more of this than the 2GB 32-bit process size limit, it is still an expensive resource. The DiskStore thread keeps it under control. If you are concerned about CPU utilization and locking in the DiskStore, you can set the diskExpiryThreadIntervalSeconds to a high number, such as 1 day. Or, you can effectively turn it off by setting the diskExpiryThreadIntervalSeconds to a very large value.
|
Feedback