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/Type and Size"
m |
|||
Line 6: | Line 6: | ||
|examples=y | |examples=y | ||
|example= | |example= | ||
− | *[[EclipseLink/Examples/JPA/Caching|Caching]] | + | *[[EclipseLink/Examples/JPA/Caching|How to use EclipseLink Caching]] |
}} | }} | ||
=Cache Type and Size= | =Cache Type and Size= | ||
− | EclipseLink | + | EclipseLink provides several different cache types which have different memory requirements. The size of the cache (in number of cached objects) can also be configured. The cache type and size to use depends on the application, the possibility of stale data, the amount of memory available in the JVM and on the machine, the garbage collection cost, and the amount of data in the database. |
− | + | By default EclipseLink uses a <code>SoftCache</code> with an initial size of 100 objects. The cache size is not fixed, but just the initial size, EclipseLink will never eject an object from the cache until it has garbage collected from memory (unless Cache is used, but this is not recommended). The cache size of the <code>SoftCache</code> and <code>HardCache</code> is also the size of the soft or hard sub-cache that can determine a minimum number of objects to hold in memory. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
<span id="Table 98-1"></span> | <span id="Table 98-1"></span> | ||
− | ''''' Cache | + | ''''' Cache Options''''' |
− | {| class="HRuleFormal" dir="ltr" title="Cache | + | {| class="HRuleFormal" dir="ltr" title="Cache Options" summary="This table describes the cache options provided." width="100%" border="1" frame="hsides" rules="rows" cellpadding="3" frame="hsides" rules="rows" |
|- align="left" valign="top" | |- align="left" valign="top" | ||
− | ! id="r1c1-t3" align="left" valign="bottom" | '''Option ( | + | ! id="r1c1-t3" align="left" valign="bottom" | '''Option (cache type)''' |
! id="r1c2-t3" align="left" valign="bottom" | '''Caching''' | ! id="r1c2-t3" align="left" valign="bottom" | '''Caching''' | ||
! id="r1c3-t3" align="left" valign="bottom" | '''Guaranteed Identity''' | ! id="r1c3-t3" align="left" valign="bottom" | '''Guaranteed Identity''' | ||
Line 30: | Line 26: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r2c1-t3" headers="r1c1-t3" align="left" | | | id="r2c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[#Full | + | [[#Full|Full]]<br /> |
| headers="r2c1-t3 r1c2-t3" align="left" | | | headers="r2c1-t3 r1c2-t3" align="left" | | ||
Yes | Yes | ||
Line 39: | Line 35: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r3c1-t3" headers="r1c1-t3" align="left" | | | id="r3c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[#Weak | + | [[#Weak|Weak]]<br /> |
| headers="r3c1-t3 r1c2-t3" align="left" | | | headers="r3c1-t3 r1c2-t3" align="left" | | ||
Yes | Yes | ||
Line 48: | Line 44: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r4c1-t3" headers="r1c1-t3" align="left" | | | id="r4c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[#Soft | + | [[#Soft|Soft]]<br /> |
| headers="r4c1-t3 r1c2-t3" align="left" | | | headers="r4c1-t3 r1c2-t3" align="left" | | ||
Yes | Yes | ||
Line 57: | Line 53: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r5c1-t3" headers="r1c1-t3" align="left" | | | id="r5c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[# | + | [[#SoftCache|SoftCache]]<br /> |
+ | | headers="r5c1-t3 r1c2-t3" align="left" | | ||
+ | Yes | ||
+ | | headers="r5c1-t3 r1c3-t3" align="left" | | ||
+ | Yes | ||
+ | | headers="r5c1-t3 r1c4-t3" align="left" | | ||
+ | Medium-high | ||
+ | |- align="left" valign="top" | ||
+ | | id="r5c1-t3" headers="r1c1-t3" align="left" | | ||
+ | [[#HardCache|HardCache]]<br /> | ||
| headers="r5c1-t3 r1c2-t3" align="left" | | | headers="r5c1-t3 r1c2-t3" align="left" | | ||
Yes | Yes | ||
Line 66: | Line 71: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r6c1-t3" headers="r1c1-t3" align="left" | | | id="r6c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[# | + | [[#None|None]]<br /> |
| headers="r6c1-t3 r1c2-t3" align3" align="left" | | | headers="r6c1-t3 r1c2-t3" align3" align="left" | | ||
Yes | Yes | ||
Line 73: | Line 78: | ||
|- align="left" valign="top" | |- align="left" valign="top" | ||
| id="r3c1-t3" headers="r1c1-t3" align="left" | | | id="r3c1-t3" headers="r1c1-t3" align="left" | | ||
− | [[#Weak | + | [[#Weak|Weak]]<br /> |
| headers="r3c1-t3 r1c2-t3" align="left" | | | headers="r3c1-t3 r1c2-t3" align="left" | | ||
Yes | Yes | ||
Line 80: | Line 85: | ||
| headers="r3c1-t3 r1c4-t3" align="left" | | | headers="r3c1-t3 r1c4-t3" align="left" | | ||
Low | Low | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|} | |} | ||
Line 113: | Line 91: | ||
− | ==Full | + | ==Full== |
This option provides full caching and guaranteed identity: objects are never flushed from memory unless they are deleted. | This option provides full caching and guaranteed identity: objects are never flushed from memory unless they are deleted. | ||
Line 121: | Line 99: | ||
− | ==Weak | + | ==Weak== |
This option is similar to the full identity map, except that the map holds the objects by using weak references. This method allows full garbage collection and provides full caching and guaranteed identity. | This option is similar to the full identity map, except that the map holds the objects by using weak references. This method allows full garbage collection and provides full caching and guaranteed identity. | ||
Line 128: | Line 106: | ||
− | ==Soft | + | ==Soft== |
This option is similar to the weak identity map, except that the map uses soft references instead of weak references. This method allows full garbage collection and provides full caching and guaranteed identity. | This option is similar to the weak identity map, except that the map uses soft references instead of weak references. This method allows full garbage collection and provides full caching and guaranteed identity. | ||
Line 135: | Line 113: | ||
− | == | + | ==SoftCache and HardCache== |
These options are similar to the weak identity map except that they maintain a most frequently used subcache. The subcache uses soft or hard references to ensure that these objects are garbage-collected only if the system is low on memory. | These options are similar to the weak identity map except that they maintain a most frequently used subcache. The subcache uses soft or hard references to ensure that these objects are garbage-collected only if the system is low on memory. | ||
Line 145: | Line 123: | ||
For more information, see [[#What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps|What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps]]. | For more information, see [[#What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps|What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps]]. | ||
− | == | + | ==None== |
This option does not preserve object identity and does not cache objects. | This option does not preserve object identity and does not cache objects. | ||
Line 152: | Line 130: | ||
− | =Guidelines for Configuring the Cache | + | =Guidelines for Configuring the Cache Type= |
You can configure the cache at the project or descriptor level. | You can configure the cache at the project or descriptor level. | ||
Line 171: | Line 149: | ||
}} | }} | ||
− | ==What You May Need to Know About the Internals of Weak, Soft, and Hard | + | ==What You May Need to Know About the Internals of Weak, Soft, and Hard Cache Types== |
The <tt>WeakIdentiyMap</tt> and <tt>SoftIdentityMap</tt> use JVM weak and soft references to ensure that any object referenced by the application is held in the cache. Once the application releases its' reference to the object, the JVM is free to garbage collection the objects. When a weak and soft reference is garbage collected - is determined by the JVM. In general one could expect a weak reference to be garbage collected on each JVM garbage collector, and a soft reference to be garbage collected when the JVM determines memory is low. | The <tt>WeakIdentiyMap</tt> and <tt>SoftIdentityMap</tt> use JVM weak and soft references to ensure that any object referenced by the application is held in the cache. Once the application releases its' reference to the object, the JVM is free to garbage collection the objects. When a weak and soft reference is garbage collected - is determined by the JVM. In general one could expect a weak reference to be garbage collected on each JVM garbage collector, and a soft reference to be garbage collected when the JVM determines memory is low. | ||
Line 193: | Line 171: | ||
{{EclipseLink_JPA | {{EclipseLink_JPA | ||
− | |previous= [[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Shared and Isolated|Shared | + | |previous= [[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Shared and Isolated|Shared, Isolated, and Protected Cache]] |
|next=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Expiration|Cache Expiration]] | |next=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Expiration|Cache Expiration]] | ||
|up=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching|Caching]] | |up=[[EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching|Caching]] | ||
− | |version=2. | + | |version=2.4 DRAFT}} |
Revision as of 13:35, 9 May 2012
EclipseLink JPA
EclipseLink | |
Website | |
Download | |
Community | |
Mailing List • Forums • IRC • mattermost | |
Issues | |
Open • Help Wanted • Bug Day | |
Contribute | |
Browse Source |
Examples
Cache Type and Size
EclipseLink provides several different cache types which have different memory requirements. The size of the cache (in number of cached objects) can also be configured. The cache type and size to use depends on the application, the possibility of stale data, the amount of memory available in the JVM and on the machine, the garbage collection cost, and the amount of data in the database.
By default EclipseLink uses a SoftCache
with an initial size of 100 objects. The cache size is not fixed, but just the initial size, EclipseLink will never eject an object from the cache until it has garbage collected from memory (unless Cache is used, but this is not recommended). The cache size of the SoftCache
and HardCache
is also the size of the soft or hard sub-cache that can determine a minimum number of objects to hold in memory.
Cache Options
Option (cache type) | Caching | Guaranteed Identity | Memory Use |
---|---|---|---|
Yes |
Yes |
Very High | |
Yes |
Yes |
Low | |
Yes |
Yes |
High | |
Yes |
Yes |
Medium-high | |
Yes |
Yes |
Medium-high | |
Yes |
Very High | ||
Yes |
Yes |
Low |
For more information, see Guidelines for Configuring the Cache and Identity Maps.
Full
This option provides full caching and guaranteed identity: objects are never flushed from memory unless they are deleted.
It caches all objects and does not remove them. Cache size doubles whenever the maximum size is reached. This method may be memory-intensive when many objects are read. Do not use this option on batch operations.
We recommend using this identity map when the data set size is small and memory is in large supply.
Weak
This option is similar to the full identity map, except that the map holds the objects by using weak references. This method allows full garbage collection and provides full caching and guaranteed identity.
The weak identity map uses less memory than full identity map but also does not provide a durable caching strategy across client/server transactions. Objects are available for garbage collection when the application no longer references them on the server side (that is, from within the server JVM).
Soft
This option is similar to the weak identity map, except that the map uses soft references instead of weak references. This method allows full garbage collection and provides full caching and guaranteed identity.
The soft identity map allows for optimal caching of the objects, while still allowing the JVM to garbage collect the objects if memory is low.
SoftCache and HardCache
These options are similar to the weak identity map except that they maintain a most frequently used subcache. The subcache uses soft or hard references to ensure that these objects are garbage-collected only if the system is low on memory.
The soft cache weak identity map and hard cache weak identity map provide more efficient memory use. They release objects as they are garbage-collected, except for a fixed number of most recently used objects. Note that weakly cached objects might be flushed if the transaction spans multiple client/server invocations. The size of the subcache is proportional to the size of the identity map as specified by the ClassDescriptor method setIdentityMapSize. You should set this cache size to be as large as the maximum number of objects (of the same type) referenced within a transaction.
We recommend using this identity map in most circumstances as a means to control memory used by the cache.
For more information, see What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps.
None
This option does not preserve object identity and does not cache objects.
We do not recommend using the no identity map option. Instead, review the alternatives of cache invalidation and isolated caching.
Guidelines for Configuring the Cache Type
You can configure the cache at the project or descriptor level.
Use the following guidelines when configuring your cache and identity map:
- If objects with a long life span and object identity are important, use a SoftIdentityMap, SoftCacheWeakIdentityMap or HardCacheWeakIdentityMap policy. For more information on when to choose one or the other, see What you may need to Know About the Internals of Weak, Soft, and Hard Identity Maps.
- If object identity is important, but caching is not, use a WeakIdentityMap policy.
- If an object has a long life span or requires frequent access, or object identity is important, use a FullIdentityMap policy.
Warning: Use the FullIdentityMap only if the class has a small number of finite instances. Otherwise, a memory leak will occur.
- If an object has a short life span or requires frequent access, and identity is not important, use a CacheIdentityMap policy.
- If objects are discarded immediately after being read from the database, such as in a batch operation, use a NoIdentityMap policy. The NoIdentityMap does not preserve object identity.
Note: We do not recommend the use of CacheIdentityMap and NoIdentityMap policies.
What You May Need to Know About the Internals of Weak, Soft, and Hard Cache Types
The WeakIdentiyMap and SoftIdentityMap use JVM weak and soft references to ensure that any object referenced by the application is held in the cache. Once the application releases its' reference to the object, the JVM is free to garbage collection the objects. When a weak and soft reference is garbage collected - is determined by the JVM. In general one could expect a weak reference to be garbage collected on each JVM garbage collector, and a soft reference to be garbage collected when the JVM determines memory is low.
The SoftCacheWeakIdentityMap and HardCacheWeakIdentityMap types of identity map contain the following two caches:
- Reference cache: implemented as a LinkedList that contains soft or hard references, respectively.
- Weak cache: implemented as a HashMap that contains weak references.
When you create a SoftCacheWeakIdentityMap or HardCacheWeakIdentityMap with a specified size, the reference cache LinkedList is exactly this size. The weak cache HashMap is initialized to 100 percent of the specified size: the weak cache will grow when more objects than the specified size are read in. Because EclipseLink does not control garbage collection, the JVM can reap the weakly held objects whenever it sees fit.
Because the reference cache is implemented as a LinkedList, new objects are added to the end of the list. Because of this, it is by nature a least recently used (LRU) cache: fixed size, object at the top of the list is deleted, provided the maximum size has been reached.
The SoftCacheWeakIdentityMap and HardCacheWeakIdentityMap are essentially the same type of identity map. The HardCacheWeakIdentityMap was constructed to work around an issue with some JVMs.
If your application reaches a low system memory condition frequently enough, or if your platform's JVM treats weak and soft references the same, the objects in the reference cache may be garbage-collected so often that you will not benefit from the performance improvement provided by it. If this is the case, we recommend that you use the HardCacheWeakIdentityMap. It is identical to the SoftCacheWeakIdentityMap except that it uses hard references in the reference cache. This guarantees that your application will benefit from the performance improvement provided by it.
When an object in a HardCacheWeakIdentityMap or SoftCacheWeakIdentityMap is pushed out of the reference cache, it gets put in the weak cache. Although it is still cached, EclipseLink cannot guarantee that it will be there for any length of time because the JVM can decide to garbage-collect weak references at anytime.