Seize the deal!
You missed out!
Imagine having a tool that can automatically detect JPA and Hibernate performance issues. Hypersistence Optimizer is that tool!
A system of record is the authoritative data source when information is scattered among various data providers. When we introduce a caching solution, we automatically duplicate our data. To avoid inconsistent reads and data integrity issues, it’s very important to synchronize the database and the cache (whenever a change occurs in the system).
There are various ways to keep the cache and the underlying database in sync and this article will present some of the most common cache synchronization strategies.
The application code can manually manage both the database and the cache information. The application logic inspects the cache before hitting the database and it updates the cache after any database modification.
Mixing caching management and application is not very appealing, especially if we have to repeat these steps in every data retrieval method. Leveraging an Aspect-Oriented caching interceptor can mitigate the cache leaking into the application code, but it doesn’t exonerate us from making sure that both the database and the cache are properly synchronized.
Instead of managing both the database and the cache, we can simply delegate the database synchronization to the cache provider. All data interaction is, therefore, done through the cache abstraction layer.
Upon fetching a cache entry, the Cache verifies the cached element availability and loads the underlying resource on our behalf. The application uses the cache as the system of record and the cache is able to auto-populate on demand.
Analogous to the read-through data fetching strategy, the cache can update the underlying database every time a cache entry is changed.
Although the database and the cache are updated synchronously, we have the liberty of choosing the transaction boundaries according to our current business requirements.
To speed up the write operations, we can simply enqueue the cache changes and periodically flush them to the database.
This strategy is employed by the Java Persistence EntityManager (first-level cache), all entity state transitions being flushed towards the end of the current running transaction (or when a query is issued).
To guarantee strong consistency, the buffer must be flushed prior to executing any query or read operation.
The advantage of the write-behind caching strategy is that we can batch the database DML statements, therefore improving transaction response time.