Hibernate Caching

Hibernate Caching is a mechanism used to reduce database calls by storing frequently accessed data in memory.

Instead of querying the database repeatedly for the same data, Hibernate retrieves it from the cache, improving performance.

In simple words:

Hibernate cache keeps data in memory so the database is not queried again and again for the same data.

---

Why Hibernate Caching Is Important

• Improves application performance
• Reduces database load
• Faster response time for read operations
• Increases scalability
• Very useful for read-heavy applications

---

Types of Caching in Hibernate

Hibernate supports three levels of caching:

Hibernate always checks caches in this order.

1. First-Level Cache (L1 Cache)

The First-Level Cache (L1 Cache), also known as the Session Cache, is the default caching mechanism in Hibernate.

It is automatically enabled and is tightly bound to a single Hibernate Session. This cache cannot be disabled and works behind the scenes to improve performance.

Whenever an entity is fetched from the database, Hibernate stores it in the first-level cache. If the same entity is requested again within the same session, Hibernate returns it directly from memory instead of executing another SQL query.

How First-Level Cache Works

• The first database call loads the entity and stores it in the session cache
• Any repeated access to the same entity within the same session does not hit the database
• The cache exists only for the lifetime of the session
• Once the session is closed, the cache is automatically cleared

Example

Sessionsession= sessionFactory.openSession();

Useru1= session.get(User.class,1L);// Database hit
Useru2= session.get(User.class,1L);// Retrieved from L1 cache

session.close();

Key Points

• Only one SQL query is executed.
• Cache lifetime equals the session lifetime.
• Cache is not shared across sessions.
• Improves performance by avoiding duplicate database calls.

---

2. Second-Level Cache (L2 Cache)

The Second-Level Cache (L2 Cache) is an optional caching mechanism in Hibernate that stores entity data across multiple sessions.

Unlike the First-Level Cache, which is limited to a single Session, the L2 cache works at the SessionFactory level and is shared among all sessions. This allows Hibernate to reuse cached data even when different sessions request the same entity.

How Second-Level Cache Works

1. Data is fetched from the database on the first request
2. Hibernate stores the entity data in the Second-Level Cache
3. When another session requests the same data, Hibernate reads it from cache instead of the database
4. This dramatically reduces database load and improves performance

Entity Configuration Example

@Entity
@Cacheable
@org.hibernate.annotations.Cache(
    usage = CacheConcurrencyStrategy.READ_WRITE
)
public class Product {
}

Popular Second-Level Cache Providers

Hibernate does not provide a cache itself. Instead, it integrates with external cache providers such as:

• Ehcache (most commonly used)
• Caffeine (high-performance, in-memory cache)
• Hazelcast (distributed cache)
• Infinispan (enterprise-grade caching)
• Redis (via integration, distributed caching)

When Should You Use Second-Level Cache?

Use Second-Level Cache when:

• Data is read frequently
• Data rarely changes
• Same data is accessed by multiple sessions
• You are working with lookup or reference data, such as:
  • User roles
  • Country codes
  • Configuration values
  • Application constants

---

3. Query Cache

The Query Cache is a caching mechanism in Hibernate that stores the results of queries rather than the entity data itself.

It depends on the Second-Level Cache (L2 Cache) to fetch actual entity data and is disabled by default.

Using the query cache can improve performance for repeated queries by avoiding database hits for the same query.

How Query Cache Works

1. When a query runs for the first time, Hibernate stores the IDs of the resulting entities in the query cache.
2. On subsequent executions of the same query, Hibernate retrieves the IDs from the query cache.
3. The actual entity data is then loaded from the L2 cache.

This reduces database queries for frequently executed read-only queries.

Example Usage

Queryquery= session.createQuery("from Product");
query.setCacheable(true);// Enable query caching
List<Product> products = query.list();

Important Notes

• Query cache does not store entity data, only IDs
• Highly dynamic or frequently changing queries are not suitable for query caching
• Always ensure the L2 cache is enabled for the entities used in query cache

---

Hibernate Caching: L1 vs L2 vs Query Cache

Hibernate provides three levels of caching to improve performance and reduce database load: First-Level Cache (L1), Second-Level Cache (L2), and Query Cache.

Feature	First-Level Cache (L1)	Second-Level Cache (L2)	Query Cache
Scope	Hibernate Session (one session)	SessionFactory (shared across sessions)	SessionFactory (relies on L2 cache)
Enabled By Default?	Yes, cannot be disabled	No, optional	No, disabled by default
Data Stored	Entities loaded in the session	Entities shared across sessions	Query result IDs (entities fetched from L2)
Cache Lifetime	Tied to session lifetime	Tied to SessionFactory lifetime	Depends on L2 cache and query configuration
Shared Across Sessions?	No	Yes	Yes, indirectly via L2 cache
Use Case	Avoid duplicate database calls within the same session	Reduce DB hits for frequently read, rarely updated entities	Speed up repeated query execution
Example	session.get(User.class, 1L)	@Cacheable on entity like Product	query.setCacheable(true)

---

Cache Concurrency Strategies

Hibernate offers different caching strategies to control how cached data is read, updated, and synchronized. Choosing the right strategy ensures data consistency, performance, and safety in concurrent applications.

1. READ_ONLY

• Best for immutable data that never changes.
• Provides the fastest performance because no synchronization is needed.
• Example: Lookup tables like country codes, roles, or static reference data.
• Safe only for data that does not get updated.

2. READ_WRITE

• Suitable for read-heavy data with occasional updates.
• Synchronizes cache with database updates to maintain consistency.
• Example: Product catalog with infrequent price or stock changes.
• Provides a balance between performance and consistency.

3. NONSTRICT_READ_WRITE

• Allows temporary inconsistencies in cached data.
• Faster than READ_WRITE because synchronization is less strict.
• Example: Reporting or analytics data where minor stale reads are acceptable.
• Prioritizes speed over strict consistency.

4. TRANSACTIONAL

• Critical data requiring full transactional consistency.
• Requires JTA (Java Transaction API) support.
• Example: Banking or financial transactions.
• Guarantees strong consistency but may have higher overhead.

Summary Table:

Strategy	Use Case
READ_ONLY	Immutable data (fastest)
READ_WRITE	Read-heavy, occasional updates
NONSTRICT_READ_WRITE	Allows stale data
TRANSACTIONAL	Full transactional consistency (JTA)

---

Cache Eviction

Cache eviction is the process of removing data from the cache to keep it consistent and free up memory. This ensures that stale or outdated data does not affect your application.

1. Manual Eviction

You can explicitly remove cached entities or entire cache regions using Hibernate APIs:

sessionFactory.getCache().evictEntityData(Product.class);

• Use this when you know the cached data is outdated or needs to be refreshed.
• Gives you fine-grained control over what is evicted.

2. Automatic Eviction

Hibernate can automatically evict cached data in certain situations:

• When an entity is updated or deleted
• When a transaction is rolled back
• On TTL (Time-to-Live) expiry, depending on the cache provider
• Ensures that cached data does not become stale
• Helps reduce memory usage and maintain data consistency

---

When to Use Caching

Use Cache When:

• Data is read frequently
• Data changes rarely
• Same data is requested repeatedly

Avoid Cache When:

• Data changes very frequently
• Strong real-time consistency is required
• Large result sets
• Real-time data (e.g., stock prices)

---

Common Mistakes

• Caching highly mutable data
• Overusing query cache
• Forgetting cache eviction
• Assuming cache is always up-to-date

---

Hibernate Cache vs Database Cache

Feature	Hibernate Cache	Database Cache
Level	Operates at the ORM (Hibernate) level	Managed by the database engine
Awareness	Entity-aware – understands entities and relationships	Row/page-based – works with raw database rows or pages
Scope	Application-specific – used within the application/session	Shared across all applications accessing the database

---

Conclusion

Hibernate caching improves performance by reducing repeated database calls and lowering database load, especially in read-heavy applications. The first-level cache works automatically within a session, while the second-level cache shares data across sessions for frequently read, rarely updated data. The query cache can further optimize performance but should be used carefully.

Caching should be applied selectively—using it for stable, read-heavy data boosts performance and scalability, but caching frequently changing data can cause consistency issues.