|Mailing List • Forums • IRC • mattermost|
|Open • Help Wanted • Bug Day|
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
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.