When using Ehcache as a second-level cache, where is the cache stored and how is it managed?

When Ehcache is configured as a second-level cache provider for JPA, it intercepts entity, collection, and query data to reduce database access. It operates transparently to the application, caching data that has been read or written from the database. The storage location and management of this cached data are central to its performance and reliability.

Cache Storage Locations

Ehcache supports a multi-tier caching architecture, allowing data to be stored in different locations with varying performance characteristics and persistence levels. This tiered approach optimizes for both speed and capacity.

• Heap (In-memory): The fastest tier, where cache entries are stored directly in the Java Virtual Machine's heap memory. This is the default and most common storage location, providing very low latency access. However, it is limited by available JVM heap space and is volatile (data is lost upon application restart).
• Off-heap (Direct Memory): An optional tier where cache entries are stored outside the JVM's garbage-collected heap, directly in native memory. This allows for larger caches without impacting garbage collection performance and can overcome some heap size limitations. Like heap storage, it's typically volatile unless configured otherwise for persistence.
• Disk (Persistent Storage): The slowest but largest and persistent tier. Cache entries can be written to disk, allowing the cache to grow beyond available RAM and persist across application restarts. Ehcache can store data on disk using its own file-based storage mechanism. This is particularly useful for warm-up times and for very large datasets that don't fit entirely in memory.

The configuration specifies the order and capacity of these tiers, and Ehcache intelligently moves entries between them based on access patterns and available space, often moving less frequently used items from faster to slower tiers.

Cache Management

Ehcache provides extensive configuration options and mechanisms to manage the lifecycle and behavior of the cached data, ensuring optimal performance and resource utilization.

• Configuration (ehcache.xml): Ehcache is primarily configured through an ehcache.xml file. This XML file defines cache managers, individual cache regions, storage tiers (heap, off-heap, disk), size limits for each tier, eviction policies, expiration policies, and other settings. This declarative approach allows developers to fine-tune cache behavior without code changes.
• Eviction Policies: When a cache reaches its configured size limit, Ehcache uses eviction policies to decide which entries to remove to make space for new ones. Common policies include:
• * LRU (Least Recently Used): Removes the entry that has not been accessed for the longest time.
• * LFU (Least Frequently Used): Removes the entry that has been accessed the fewest times.
• * FIFO (First In, First Out): Removes the entry that was added to the cache first.
• Expiration Policies: Cache entries can be configured to expire automatically after a certain period, regardless of whether the cache is full. This prevents stale data from being served. Key policies include:
• * TTL (Time To Live): An entry expires a fixed amount of time after it was created or last updated.
• * TTI (Time To Idle): An entry expires if it has not been accessed for a fixed amount of time.
• Cache Statistics and Monitoring: Ehcache provides JMX-enabled MBeans for monitoring cache performance, hit/miss ratios, entry counts, eviction counts, and memory usage. This allows administrators to observe cache behavior in real-time and identify areas for optimization.
• Cache Invalidation and Updates: When entities are updated or deleted through JPA, Ehcache, as the second-level cache, must be notified to invalidate or update the corresponding cache entries. JPA providers (like Hibernate) integrate with Ehcache to handle this automatically when changes occur within the same transaction manager. For external updates, manual invalidation or sophisticated invalidation strategies (e.g., event listeners) might be required.
• Clustering/Distributed Caching: For distributed environments, Ehcache can be integrated with Terracotta's enterprise capabilities to create a clustered cache. This allows multiple application instances to share the same cache data, providing consistency and scalability across a cluster. It manages cache coherence and data replication among nodes.

By strategically combining storage tiers and robust management features, Ehcache effectively serves as a high-performance and scalable second-level cache for JPA applications.