EclipseLink/UserGuide/JPA/Basic JPA Development/Caching/Caching Overview
|Mailing List • Forums • IRC|
The EclipseLink cache is an in-memory repository that stores recently read or written objects based on class and Id values. EclipseLink uses the cache to do the following:
- Improve performance by holding recently read or written objects and their relationships and accessing them in-memory to minimize database access.
- Manage locking and isolation level.
- Manage object identity.
EclipseLink offers an integrated and functional cache including the following features:
- Isolated persistence context cache (L1), and shared persistence unit cache (L2)
- Caching configurable at the Entity level, entities can be cached, or not, cached entities can reference non-cached entities
- Multiple cache type options (weak, soft, full, weak-cache, soft-cache)
- Configurable size
- Read-only entities
- Cache indexes
- Query-level cache options
- In-memory querying and conforming
- Time to live, and daily cache invalidation
- Clustered cache coordination through RMI and JMS
- Database event driven cache invalidation and Oracle DCN/QCN
- Support for JPA 2.0 @Cachable configuraiton and API
- Extended JpaCache API
- Query cache
EclipseLink supports the following caching annotations:
- @Cachable (JPA 2.0)
EclipseLink also provides a number of persistence unit properties that you can specify to configure the EclipseLink cache. These properties may compliment or provide an alternative to the usage of annotations. Caching options can also be configured through the EclipseLink Java API using a
EclipseLink uses two types of cache: the shared persistence unit cache (L2) maintains objects retrieved from and written to the data source; and the isolated persistence context cache (L1) holds objects while they participate in transactions. When a persistence context (entity manager) successfully commits to the data source, EclipseLink updates the persistence unit cache accordingly. Conceptually the persistence context cache is represented by the
EntityManager and the persistence unit cache is represented by the
Internally EclipseLink stores the persistence unit cache on an EclipseLink session, and the persistence context cache on an EclipseLink unit of work. As this figure shows, the persistence unit cache (session) cache and the persistence context cache (unit of work cache) work together with the data source connection to manage objects in an EclipseLink application. The object life cycle relies on these three mechanisms.
Object Life Cycle and the EclipseLink Caches
Persistence Unit Cache
The persistence unit cache (L2) is a shared cache that services clients attached to a given persistence unit. When you read objects from or write objects to the data source using an
EntityManager, EclipseLink saves a copy of the objects in the persistence unit cache's cache and makes them accessible to all other processes accessing the same persistence unit.
EclipseLink adds objects to the persistence unit cache from the following:
- The data store, when EclipseLink executes a read operation
- The persistence context cache, when a persistence context successfully commits a transaction
EclipseLink defines three cache isolation levels:
- Isolated - entities are only cached in the persistence context, not in the persistence unit
- Shared - entities are cached both in the persistence context and persistence unit, read-only entities are shared and only cache in the persistence unit
- Protected - entities are cached both in the persistence context and persistence unit, read-only entities are isolated and cached in the persistence unit and persistence context
For more information, see Shared, Isolated and Protected.
There is a separate persistence unit cache for each unique persistence unit name. Although the cache is conceptually stored with the
EntityManagerFactory, in EclipseLink two factories with the same persistence unit name will share the same cache (and effectively be the same persistence unit instance). If the same persistence unit is deployed in two separate applications in Java EE, their full persistence unit name will normally still be unique, and they will use separate caches. Certain persistence unit properties, such as data-source, database URL, user, and tenant id can affect the unique name of the persistence unit, and result in seperate persistence unit instances and separate caches. The
"eclipselink.session.name" persistence unit property can be used to force two persistence units to resolve to the same instance and share a cache.
Persistence Context Cache
The unit of work cache services operations within the unit of work. It maintains and isolates objects from the session cache, and writes changed or new objects to the session cache after the unit of work commits changes to the data source.