The Second-Level Cache

Introduction

In the previous lesson, you saw the first-level cache: a mandatory, per-Session cache that lasts only as long as that one Session is open. The second-level cache is different in every one of those ways. It is optional, it lives at the SessionFactory level, and it is shared across every Session your application opens.

That difference matters because the first-level cache cannot help two separate requests that both load the same Employee with id 7 — each request gets its own Session, so each one hits the database. A second-level cache can serve the second request straight from memory instead.

First-Level vs Second-Level

It helps to see the two side by side before touching any configuration.

How It Works

When the second-level cache is enabled for an entity, Hibernate stores a disassembled, cache-provider-friendly representation of that entity keyed by its identifier. The next time any Session asks for that entity by id, Hibernate checks the second-level cache first. Only on a miss does it fall through to a SQL query against the database.

Enabling a Cache Provider

Hibernate does not ship its own cache implementation — it delegates to a caching provider through the JCache (JSR-107) API or a native integration. Ehcache is the most common choice. First, add the dependency, then turn on second-level caching in your Hibernate configuration.

<dependency>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-jcache</artifactId>
    <version>6.4.4.Final</version>
</dependency>
<dependency>
    <groupId>org.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>3.10.8</version>
</dependency>

<property name="hibernate.cache.use_second_level_cache">true</property>
<property name="hibernate.cache.region.factory_class">jcache</property>
<property name="hibernate.javax.cache.provider">org.ehcache.jsr107.EhcacheCachingProvider</property>
<property name="hibernate.cache.use_query_cache">false</property>

That last property, use_query_cache, is off by default here on purpose — enable it separately only if you plan to cache specific HQL query results, since query caching has its own overhead and invalidation rules.

Caching an Entity

Enabling the provider is not enough by itself — you must opt each entity into caching individually with @Cacheable and tell Hibernate which concurrency strategy to use.

import javax.persistence.*;
import org.hibernate.annotations.Cache;
import org.hibernate.annotations.CacheConcurrencyStrategy;

@Entity
@Table(name = "products")
@Cacheable
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private Double price;

    // Getters and setters
}

SessionFactory factory = new Configuration().configure().buildSessionFactory();

try (Session session1 = factory.openSession()) {
    Product p = session1.get(Product.class, 1L);   // Hits the database
    System.out.println(p.getName());
}

try (Session session2 = factory.openSession()) {
    Product p = session2.get(Product.class, 1L);   // Served from the second-level cache
    System.out.println(p.getName());
}

Cache Concurrency Strategies

The usage attribute on @Cache tells Hibernate how carefully it needs to guard against stale or inconsistent cached data. Pick the weakest strategy that is still safe for the data in question.

When It Is Worth It

The second-level cache is a real win for data that is read far more often than it is written, and where a small window of staleness is tolerable — think product catalogs, lookup/reference tables, or configuration entities. It is a poor fit for data that changes constantly, since the cache invalidation overhead can end up costing more than it saves.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

The second-level cache extends caching beyond a single Session, letting rarely-changing entities be served from memory across your whole application instead of hitting the database every time. It is powerful but not free — enable it deliberately, entity by entity, based on actual read/write patterns rather than by default.