Part 2, Chapter 16 Every new chapter of my book is released right after it’s being completed, so the reader doesn’t have to wait for the whole part to be finished to get access to new material. Table of content This chapter explains how enterprise caching works, from database internal buffers, to application-level caching, and the second-level cache offered by Hibernate.
A small company with big dreams I first heard of Speedment while watching a Hazelcast webinar about a RDBMS Change Data Capture approach for updating the in-memory data grid. Their products are very much in-line with Greg Luck’s Deliberate caching and I can see many enterprise products gaining from this new paradigm shift. We have the pleasure of talking to Per-Åke Minborg, who is the CTO and one of the founders of Speedment AB.
Introduction Now that I covered both Entity and Collection caching, it’s time to investigate how Query Caching works. The Query Cache is strictly related to Entities, and it draws an association between a search criterion and the Entities fulfilling that specific query filter. Like other Hibernate features, the Query Cache is not as trivial as one might think.
Introduction In my previous post, I introduced the READ_WRITE second-level cache concurrency mechanism. In this article, I am going to continue this topic with the TRANSACTIONAL strategy.
Introduction In my previous post, I introduced the NONSTRICT_READ_WRITE second-level cache concurrency mechanism. In this article, I am going to continue this topic with the READ_WRITE strategy.
Introduction In my previous post, I introduced the READ_ONLY CacheConcurrencyStrategy, which is the obvious choice for immutable entity graphs. When cached data is changeable, we need to use a read-write caching strategy and this post will describe how NONSTRICT_READ_WRITE second-level cache works.
Introduction Previously, I described the second-level cache entry structure, Hibernate uses for storing entities. Besides entities, Hibernate can also store entity associations and this article will unravel the inner workings of collection caching.
Introduction As I previously explained, enterprise caching requires diligence. Because data is duplicated between the database (system of record) and the caching layer, we need to make sure the two separate data sources don’t drift apart. If the cached data is immutable (neither the database nor the cache is able to modify it), we can safely cache it without worrying about any consistency issues. Read-only data is always a good candidate for application-level caching, improving read performance without having to relax consistency guarantees.
Introduction 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.
Introduction Relational database transactions are ACID and the strong consistency model simplifies application development. Because enabling Hibernate caching is one configuration away, it’s very appealing to turn to caching whenever the data access layer starts showing performance issues. Adding a caching layer can indeed improve application performance, but it has its price and you need to be aware of it.