Data Freshness
Many databases and other systems of record (SORs) are not built to accommodate caching outside of the database. This means that they do not normally come with any default mechanism for notifying external processes when data has been updated or modified. If Ehcache is used to cache data from such a database or SOR, Ehcache will not be automatically informed if data in the database or SOR has changed.
This leads to the idea of data freshness: if a set of data in the cache still largely matches (in other words, most of the cached data entries are still in sync with) the data in the original data in the database or SOR, the data is termed fresh, but if many changes in the database or SOR have occurred without the cache also being updated, the data in the cache becomes increasing less fresh - it becomes stale.
When using Ehcache as a caching system, the following strategies can help to keep the data in the cache fresh, i.e. in sync with the database or SOR:
Data Expiry: Use the eviction algorithms included with
Ehcache, along with the time-to-idle (TTI) and time-to-live (TTL) settings, to enforce a maximum time for elements to live in the cache (forcing a re-load from the database or SOR). See the section
Expiry for related information.
Message Bus: Use an application to make all updates to the database. When updates are made, post a message onto a message queue with a key to the item that was updated. All application instances can subscribe to the message bus and receive messages about data that is updated, and can synchronize their local copy of the data accordingly (for example by invalidating the cache entry for updated data).
Triggers: Using a database trigger can accomplish a similar task as the message bus approach. Use the database trigger to execute code that can publish a message to a message bus. The advantage to this approach is that updates to the database do not have to be made only through a special application. The downside is that not all database triggers support full execution environments and it is often inadvisable to execute heavy-weight processing such as publishing messages on a queue during a database trigger.
The Data Expiry strategy is the simplest and most straightforward. It gives you the most control over the data synchronization, and doesn't require cooperation from any external systems. You simply set a data expiry policy and let Ehcache expire data from the cache, thus allowing fresh reads to re-populate and re-synchronize the cache.
If you choose the Data Expiry strategy, the most important consideration is balancing data freshness with database load. The shorter you make the expiry settings - meaning the more "fresh" you try to make the data - the more load you will place on the database.
Try out some numbers for time-to-idle and time-to-live and see what kind of load your application generates. Even modestly short values such as five or ten minutes can produce significant load reductions.