February 26, 2021
Hot Topics:

EclipseLink Caching Ability, Page 4

EclipseLink Caching Ability

Data caching is essential when building an enterprise application. It becomes the most important aspect of an application when the app requires lots of database access. Caching speeds up database access and increases the performance of an application. JPA 2 supports two Levels of caches: JPA Level 1 Cache (L1) and JPA Level 2 Cache (L2). L1 cache is the persistence context and L2 cache spans across different persistence context. Find more info on JPA 2 Cache in the article JPA 2.0 Cache Vs. Hibernate Cache: Differences in Approach.

Every persistence provider has to implement the JPA 2.0 specification to provide the caching facility to cache row objects. In addition to implementing JPA 2, EclipseLink is capable of caching entities, which yields much better performance for the application. This section introduces the basics of the EclipseLink caching capability (covering every aspect of EclipseLink caching is beyond the scope of this article).

EclipseLink supports two types of cache:

  1. Session cache
  2. Unit of workcache

Session cache and unit of work cache work together to optimize the application's database access. Instances that are stored and retrieved from the database are managed and maintained by the Session cache. The Session cache stores instances that can be retrieved for future reference beyond the scope of the transaction. The first object accessed from the database is eligible to be added to the Session scope. The Unit of work cache stores instances within that transaction. When the transaction gets completed, the state of the instance gets synchronized with the database. That is when EclipseLink updates the Session cache for that object.

Objects are uniquely identified in the database using their primary key values. Within the cache, the primary key value of the persistent entity is the object identity that EclipseLink uses to uniquely identify instances. The objects in the cache are stored in the Identity Map. Caching can be enabled in EclipseLink either by using either annotations or XML files. The following code snippet shows the usage of the @Cache annotation on the Student entity class.

import org.eclipse.persistence.annotations.Cache;
import org.eclipse.persistence.annotations.CacheCoordinationType;
import org.eclipse.persistence.annotations.CacheType;
import javax.persistence.Entity;
import javax.persistence.Table;
@Cache (type = CacheType.SOFT, shared=true, coordinationType=CacheCoordinationType.INVALIDATE_CHANGED_OBJECTS)
public class Student {
// Some Code

Here is how the attributes in the code function:

  • The type attribute specifies the strategy to be used while caching the object.
    • CacheType.SOFT: This instructs the garbage collector (GC) to collect the object only when the application decides that memory might be low.
    • CacheType.WEAK: The object marked is the one that will be removed as soon as the GC is initiated.
    • CacheType.FULL: This gives full caching facility, as the objects are never flushed from the memory until they are deleted from the memory.
    • CacheType.SOFT_WEAK: This is similar to the WEAK identity map, but it uses the most frequently used sub cache.
    • CacheType.HARD_WEAK: This is similar to SOFT_WEAK but it uses the hard references in the sub cache.
  • The shared attribute is set to true, which informs EclipseLink to store the object in the L2 cache shared across the persistence context.
  • The coordinationType attribute helps EclipseLink to decide what needs to be done when the state of an instance is modified. The values that this attribute can take are:
    • INVALIDATE_CHANGED_OBJECTS: Invalidates the object in other referencing nodes. The changes made in an object do not reflect in its reference.
    • SEND_OBJECT_CHANGES: When the state is changed, it is reflected in the cache.
    • SEND_NEW_OBJECTS_WITH_CHANGES: Similar to SEND_OBJECT_CHANGES, but this is applicable only for those objects that are newly created in the transactions

Caching in JPQL

JPA provides a standard and powerful querying mechanism for querying the database. JPQL is the standard querying language used to define queries in JPA. Queries that search for instances in the shared cache are called in-memory queries. A query generally searches in the database except for those that are searching for a single instance. When a query is couched for a single instance, the instance is checked in the cache and then in the database. We can specify whether the query needs to be fired against the database or against the in-memory or against both.

The eclipselink.cache-usage hint is used to specify the interaction with the EclipseLink cache. This is a shared cache that will be shared across the persistence context. The following code snippet applies a query hint using @QueryHint. It specifies the cache usage to CheckCacheByPrimaryKey, which specifies that the cache is checked first if the query contains the primary key.

@NamedQuery(name = "Employee.findAll", query = "SELECT e FROM Employee e", hints={@QueryHint(name="eclipselink.cache-usage",
value=" CheckCacheByPrimaryKey")})


In this article, we introduced the open source ORM solution, EclipseLink. We also provided the steps required to create a JPA 2 application with EclipseLink as the provider in both Java SE and Java EE environments. Towards the end of the article, we explored the EclipseLink cache, which differentiates it from other vendors implementing JPA 2 specification.


We would like to sincerely thank Mr. Subrahmanya (SV, VP, ECOM Research Group, E&R) for his constant encouragement and Ms. Sangeetha S for providing ideas, guidance and valuable comments, and for kindly reviewing this article.

About the Authors

Mahalakshmi K. works at the E-Commerce Research Labs at Infosys Technologies Ltd. on Java EE technologies. Her core interest is in researching image processing, and she is also involved in the design and development of Java EE applications using Hibernate and JPA.

Nitin KL works at the E-Commerce Research Labs at Infosys Technologies. He is involved in design and development of Java EE applications using Hibernate, iBATIS, and JPA.

Originally published on https://www.developer.com.

Page 4 of 4

This article was originally published on December 16, 2010

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date