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"
< EclipseLink | UserGuide | JPA | Basic JPA Development | Caching
m |
m |
||
| Line 5: | Line 5: | ||
|eclipselinktype=JPA}} | |eclipselinktype=JPA}} | ||
=Cache Expiration= | =Cache Expiration= | ||
| − | By default, objects remain in the session cache until they are explicitly deleted | + | By default, objects remain in the session cache until they are explicitly deleted or garbage collected when using a weak identity map. |
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. | 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. | ||
| Line 17: | Line 17: | ||
You can configure a cache invalidation policy in the following ways: | You can configure a cache invalidation policy in the following ways: | ||
| − | * At the project level that applies to all objects | + | * At the project level that applies to all objects |
| − | * At the descriptor level to override the project level configuration on a per-object basis | + | * At the descriptor level to override the project level configuration on a per-object basis |
| − | * At the query level that applies to the results returned by the query | + | * At the query level that applies to the results returned by the query |
| − | If you configure a query to cache results in its own internal cache | + | If you configure a query to cache results in its own internal 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 | + | 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. |
Revision as of 15:10, 4 May 2011
EclipseLink JPA
| EclipseLink | |
| Website | |
| Download | |
| Community | |
| Mailing List • Forums • IRC • mattermost | |
| Issues | |
| Open • Help Wanted • Bug Day | |
| Contribute | |
| Browse Source |
Cache Expiration
By default, objects remain in the session cache until they are explicitly deleted or garbage collected when using a weak identity map.
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
- At the descriptor level to override the project level configuration on a per-object basis
- At the query level that applies to the results returned by the query
If you configure a query to cache results in its own internal 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.
