Evictors remove data from the data grid. You can either set a time-based evictor or because evictors are associated with BackingMaps, use the BackingMap interface to specify the pluggable evictor.
Specifies that entries never expire and therefore are never removed from the map.
Specifies that entries are evicted depending on when they were created.
If you are using the Creation time CREATION_TIME ttlType, the evictor evicts an entry when its time from creation equals its TimeToLive attribute TTL value, which is set in milliseconds in your application configuration. If you set the TTL TimeToLive attribute value to 10 seconds, the entry is automatically evicted ten seconds after it was inserted.
It is important to take caution when setting this value for the Creation time evictor typeCREATION_TIME ttlType. This evictor is best used when reasonably high amounts of additions to the cache exist that are only used for a set amount of time. With this strategy, anything that is created is removed after the set amount of time.
The Creation time evictor type CREATION_TIME ttlType is useful in scenarios such as refreshing stock quotes every 20 minutes or less. Suppose a Web application obtains stock quotes, and getting the most recent quotes is not critical. In this case, the stock quotes are cached in a gridan ObjectGrid for 20 minutes. After 20 minutes, the grid an ObjectGrid map entries expire and are evicted. Every twenty minutes or so, the grid an ObjectGrid map uses the Loader plug-in to refreshes the data with data from the database. The database is updated every 20 minutes with the most recent stock quotes.
Specifies that entries are evicted depending upon when they were last accessed, whether they were read or updated.
Specifies that entries are evicted depending upon when they were last updated.
If you are using the Last access time LAST_ACCESS_TIME or the Last update time evictor typeLAST_UPDATE_TIME ttlType attribute, set the TTL value TimeToLive to a lower number than if you are using the Creation time evictorCREATION_TIME ttlTypebecause the entries TimeToLive attribute are reset every time it is accessed. In other words, if the TimeToLive attribute is equal to 15 and an entry has existed for 14 seconds but then gets accessed, it does not expire again for another 15 seconds. If you set the TTL value TimeToLive to a relatively high number, many entries might never be evicted. However, if you set the value to something like 15 seconds, entries might be removed when they are not often accessed.
The Last access timeLAST_ACCESS_TIME or Last update time evictor type LAST_UPDATE_TIME ttlType is useful in scenarios such as holding session data from a client, using a grid an ObjectGrid map. Session data must be destroyed if the client does not use the session data for some period of time. For example, the session data times out after 30 minutes of no activity by the client. In this case, using an evictor type of Last access time LAST_ACCESS_TIME or LAST_UPDATE_TIME Last update time with the TTL valueTimeToLive attribute set to 30 minutes is appropriate for this application.
You may also write your own evictors: For more information, see Cómo escribir un desalojador personalizado.
The default TTL evictor uses an eviction policy that is based on time, and the number of entries in the BackingMap has no affect on the expiration time of an entry. You can use an optional pluggable evictor to evict entries based on the number of entries that exist instead of based on time.
The BackingMap informs an evictor as entries are created, modified, or removed in a transaction. The BackingMap keeps track of these entries and chooses when to evict one or more entries from the BackingMap instance.
A BackingMap instance has no configuration information for a maximum size. Instead, evictor properties are set to control the evictor behavior. Both the LRUEvictor and the LFUEvictor have a maximum size property that is used to cause the evictor to begin to evict entries after the maximum size is exceeded. Like the TTL evictor, the LRU and LFU evictors might not immediately evict an entry when the maximum number of entries is reached to minimize impact on performance.
If the LRU or LFU eviction algorithm is not adequate for a particular application, you can write your own evictors to create your eviction strategy.
All built-in evictors support memory-based eviction that can be enabled on the BackingMap interface by setting the evictionTriggers attribute of BackingMap to MEMORY_USAGE_THRESHOLD. For more information about how to set the evictionTriggers attribute on BackingMap, see Interfaz BackingMap and Archivo XML de descriptor ObjectGrid.
Memory-based eviction is based on heap usage threshold. When memory-based eviction is enabled on BackingMap and the BackingMap has any built-in evictor, the usage threshold is set to a default percentage of total memory if the threshold has not been previously set.
When you are using memory-based eviction, you should configure the garbage collection threshold to the same value as their target heap utilization. For example, if the memory-based eviction threshold is set at 50 percent and the garbage collection threshold is at the default 70 percent level, then the heap utilization can go as high as 70 percent. This heap utilization increase occurs because memory-based eviction is only triggered after a garbage collection cycle.
To change the default usage threshold percentage, set the memoryThresholdPercentage property on container and server property file for eXtreme Scale server process. To set the target usage threshold on a client process, you can use the MemoryPoolMXBean.
The memory-based eviction algorithm used by WebSphere eXtreme Scale is sensitive to the behavior of the garbage collection algorithm in use. The best algorithm for memory-based eviction is the IBM® default throughput collector. Generation garbage collection algorithms can cause undesired behavior, and so you should not use these algorithms with memory-based eviction.
To change the usage threshold percentage, set the memoryThresholdPercentage property on the container and server property files for eXtreme Scale server processes.
During runtime, if the memory usage exceeds the target usage threshold, memory-based evictors start evicting entries and try to keep memory usage below the target usage threshold. However, no guarantee exists that the eviction speed is fast enough to avoid a potential out of memory error if the system runtime continues to quickly consume memory.