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"
(→Cache Expiration and Invalidation) |
|||
| Line 12: | Line 12: | ||
By default, objects remain in the shared cache until they are explicitly deleted or garbage collected. | By default, objects remain in the shared cache until they are explicitly deleted or garbage collected. | ||
| − | You can configure any | + | You can configure any entity with a <tt>expiry</tt> that lets you specify, either the number of milliseconds after which an entity instance should expire from the cache, or a time of day that all instances of the entity class should expire from the cache. Expiry is set on the <tt>@Cache</tt> annotation or <tt><cache></tt> XML element, and can be configured in two ways: |
| − | * <tt>expiry</tt> - The number of milliseconds to expiry an | + | * <tt>expiry</tt> - The number of milliseconds to expiry an entity instance in the cache after it has been read. |
| − | * <tt>expiryTimeOfDay</tt> - The <tt>@TimeOfDay</tt> represent the 24h time of day to expiry all | + | * <tt>expiryTimeOfDay</tt> - The <tt>@TimeOfDay</tt> represent the 24h time of day to expiry all instances of the entity class in the cache. |
| − | When an | + | When an instance expires, it is only invalidated in the cache. It is not removed from the cache, but when next accessed it will be refreshed from the database as part of the query that was used to access it. |
It is also possible to define your own expiry or invalidation policy by defining your own <tt>CacheInvalidationPolicy</tt> and setting it in your entity's descriptor using a <tt>DescriptorCustomizer</tt>. | It is also possible to define your own expiry or invalidation policy by defining your own <tt>CacheInvalidationPolicy</tt> and setting it in your entity's descriptor using a <tt>DescriptorCustomizer</tt>. | ||
Revision as of 15:10, 10 May 2012
EclipseLink JPA
| EclipseLink | |
| Website | |
| Download | |
| Community | |
| Mailing List • Forums • IRC • mattermost | |
| Issues | |
| Open • Help Wanted • Bug Day | |
| Contribute | |
| Browse Source |
Examples
Cache Expiration and Invalidation
By default, objects remain in the shared cache until they are explicitly deleted or garbage collected.
You can configure any entity with a expiry that lets you specify, either the number of milliseconds after which an entity instance should expire from the cache, or a time of day that all instances of the entity class should expire from the cache. Expiry is set on the @Cache annotation or <cache> XML element, and can be configured in two ways:
- expiry - The number of milliseconds to expiry an entity instance in the cache after it has been read.
- expiryTimeOfDay - The @TimeOfDay represent the 24h time of day to expiry all instances of the entity class in the cache.
When an instance expires, it is only invalidated in the cache. It is not removed from the cache, but when next accessed it will be refreshed from the database as part of the query that was used to access it.
It is also possible to define your own expiry or invalidation policy by defining your own CacheInvalidationPolicy and setting it in your entity's descriptor using a DescriptorCustomizer.
The application can also explicitly invalidate objects in the cache using the JPA Cache API, or the EclipseLink JpaCache API (see Cache API).
Expiry can also be used in the query results cache (see Query Results Cache).
Invalidation can also be used in a cluster through cache coordination (see Cache Coordination), or from database events using database event notification (see Database Events Notification).
