Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/UserGuide/JPA/Basic JPA Development/Caching/Expiration"
m (New page: =Cache Expiration= {{EclipseLink_JPA |previous= Type and Size |next=[[EclipseLink/UserGuide/JPA/Basic_JPA_Devel...) |
m (→Cache Expiration) |
||
| Line 1: | Line 1: | ||
=Cache Expiration= | =Cache Expiration= | ||
| + | By default, objects remain in the session cache until they are explicitly deleted (see [[Using%20Basic%20Unit%20of%20Work%20API%20(ELUG)|Deleting Objects]]) or garbage collected when using a weak identity map (see [[Configuring%20a%20Project%20(ELUG)|Configuring Cache Type and Size at the Project Level]]). | ||
| + | Alternatively, you can configure any object with a <tt>CacheInvalidationPolicy</tt> that lets you specify, either automatically or manually, under what circumstances a cached object is invalid: when any query attempts to read an invalid object, EclipseLink will go to the data source for the most up-to-date version of that object, and update the cache with this information. | ||
| + | |||
| + | You can use any of the following <tt>CacheInvalidationPolicy</tt> instances: | ||
| + | |||
| + | * <tt>DailyCacheInvalidationPolicy</tt><nowiki>: the object is automatically flagged as invalid at a specified time of day.</nowiki> | ||
| + | * <tt>NoExpiryCacheInvalidationPolicy</tt><nowiki>: the object can only be flagged as invalid by explicitly calling </nowiki><tt>org.eclipse.persistence.sessions.IdentityMapAccessor</tt> method <tt>invalidateObject</tt>. | ||
| + | * <tt>TimeToLiveCacheInvalidationPolicy</tt><nowiki>: the object is automatically flagged as invalid after a specified time period has elapsed since the object was read.</nowiki> | ||
| + | |||
| + | You can configure a cache invalidation policy in the following ways: | ||
| + | |||
| + | * At the project level that applies to all objects ( [[Configuring%20a%20Project%20(ELUG)|Configuring Cache Expiration at the Project Level]]) | ||
| + | * At the descriptor level to override the project level configuration on a per-object basis ( [[Configuring%20a%20Descriptor%20(ELUG)|Configuring Cache Expiration at the Descriptor Level]]) | ||
| + | * At the query level that applies to the results returned by the query ([[Using%20Advanced%20Query%20API%20(ELUG)|How to Configure Cache Expiration at the Query Level]]) | ||
| + | |||
| + | If you configure a query to cache results in its own internal cache (see [[Introduction%20to%20EclipseLink%20Queries%20(ELUG)|How to Cache Query Results in the Query Cache]]), the cache invalidation policy you configure at the query level applies to the query's internal cache in the same way it would apply to the session cache. | ||
| + | |||
| + | If you are using a coordinated cache (see [[#Cache Coordination|Cache Coordination]]), you can customize how EclipseLink communicates the fact that an object has been declared invalid. For more information, see [[Configuring%20a%20Descriptor%20(ELUG)#Configuring Cache Coordination Change Propagation at the Descriptor Level|Configuring Cache Coordination Change Propagation at the Descriptor Level]]. | ||
Revision as of 08:10, 16 June 2010
Cache Expiration
By default, objects remain in the session cache until they are explicitly deleted (see Deleting Objects) or garbage collected when using a weak identity map (see Configuring Cache Type and Size at the Project Level).
Alternatively, you can configure any object with a CacheInvalidationPolicy that lets you specify, either automatically or manually, under what circumstances a cached object is invalid: when any query attempts to read an invalid object, EclipseLink will go to the data source for the most up-to-date version of that object, and update the cache with this information.
You can use any of the following CacheInvalidationPolicy instances:
- DailyCacheInvalidationPolicy: the object is automatically flagged as invalid at a specified time of day.
- NoExpiryCacheInvalidationPolicy: the object can only be flagged as invalid by explicitly calling org.eclipse.persistence.sessions.IdentityMapAccessor method invalidateObject.
- TimeToLiveCacheInvalidationPolicy: the object is automatically flagged as invalid after a specified time period has elapsed since the object was read.
You can configure a cache invalidation policy in the following ways:
- At the project level that applies to all objects ( Configuring Cache Expiration at the Project Level)
- At the descriptor level to override the project level configuration on a per-object basis ( Configuring Cache Expiration at the Descriptor Level)
- At the query level that applies to the results returned by the query (How to Configure Cache Expiration at the Query Level)
If you configure a query to cache results in its own internal cache (see How to Cache Query Results in the Query Cache), the cache invalidation policy you configure at the query level applies to the query's internal cache in the same way it would apply to the session cache.
If you are using a coordinated cache (see Cache Coordination), you can customize how EclipseLink communicates the fact that an object has been declared invalid. For more information, see Configuring Cache Coordination Change Propagation at the Descriptor Level.
