Jump to: navigation, search

EclipseLink/UserGuide/JPA/Basic JPA Development/Caching/Caching Overview

< EclipseLink‎ | UserGuide‎ | JPA‎ | Basic JPA Development‎ | Caching
Revision as of 10:43, 7 May 2012 by James.sutherland.oracle.com (Talk | contribs) (Caching Overview)

Caching Overview

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
  • Cache indexes
  • 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)
  • @Cache
  • @ExistenceChecking

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 SessionCustomizer.

Cache Architecture

EclipseLink uses two types of cache: the session cache maintains objects retrieved from and written to the data source; and the unit of work cache holds objects while they participate in transactions. When a unit of work successfully commits to the data source, EclipseLink updates the session cache accordingly.

Note: You can also configure a query to cache its results (see How to Cache Results in a ReadQuery)

As this figure shows, the session cache and the 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

Object Life Cycle and the EclipseLink Caches

Session Cache

The session cache is a shared cache that services clients attached to a given session. When you read objects from or write objects to the data source using a client session, EclipseLink saves a copy of the objects in the parent server session's cache and makes them accessible to all other processes in the session.

EclipseLink adds objects to the session cache from the following:

  • The data store, when EclipseLink executes a read operation
  • The unit of work cache, when a unit of work successfully commits a transaction

An isolated client session is a special type of client session that provides its own session cache isolated from the shared object cache of its parent server session. The isolated client session cache can be used to improve user-based security or to avoid caching highly volatile data. Developers can choose on a per object type whether default shared session cache or the isolated client session cache is used.

For more information, see Isolated Client Sessions.

Unit of Work 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.

Version: 2.2.0 DRAFT
Other versions...