When the cache overflows, JE must evict some records from the cache. By default, JE uses a Least Recently Used (LRU) algorithm for determining which records to evict. With the LRU algorithm, JE makes a best effort to evict the "coldest" (least recently used or accessed) records and to retain the "hottest" records in the cache for as long as possible.
Note that JE uses an approximate LRU approach with some exceptions and special cases.
EnvironmentConfig.NODE_MAX_ENTRIES). When an LN is accessed, its BIN is moved to the hot end of the LRU list, implying that all other LNs in the same BIN also are treated as if they are hot. The same applies if the BIN is moved to the cold end of the LRU list.
1) Dirty BINs and INs are evicted only after eviction of all non-dirty BINs and INs. This is important to reduce logging and associated cleaning costs.
2) A BIN may be mutated to a BIN-delta to reclaim memory, rather
then being evicted entirely. A BIN-delta contains only the dirty
entries (for LNs recently logged). A BIN-delta is used when its
size relative to the full BIN will be small enough so that it will
be more efficient, both on disk and in memory, to store the delta
rather than the full BIN.
The advantage of keeping a BIN-delta in cache is that some
operations, particularly record insertions, can be performed using
the delta without having the complete BIN in cache. When a BIN is
mutated to a BIN-delta to reclaim memory, it is placed at the hot
end of the LRU list.
EnvironmentConfig.EVICTOR_N_LRU_LISTS. As described in the javadoc for this parameter, there is a trade-off between thread contention and the accuracy of the LRU.
When no cache mode is explicitly specified, the default cache mode is
DEFAULT. The default mode causes the normal LRU algorithm to be
An explicit cache mode may be specified as an
Environment property, a
Database property, or a
Cursor property. If none are specified,
DEFAULT is used. If more than one non-null property is specified, the
Cursor property overrides the Database and Environment properties, and the
Database property overrides the Environment property.
When all records in a given Database, or all Databases, should be treated the same with respect to caching, using the Database and/or Environment cache mode properties is sufficient. For applications that need finer grained control, the Cursor cache mode property can be used to provide a specific cache mode for individual records or operations. The Cursor cache mode property can be changed at any time, and the cache mode specified will apply to subsequent operations performed with that Cursor.
In a Replicated Environment where a non-default cache mode is desired, the cache mode can be configured on the Master node as described above. However, it is important to configure the cache mode on the Replica nodes using an Environment property. That way, the cache mode will apply to write operations that are replayed on the Replica for all Databases, even if the Databases are not open by the application on the Replica. Since all nodes may be Replicas at some point in their life cycle, it is recommended to configure the desired cache mode as an Environment property on all nodes in a Replicated Environment.
On a Replica, per-Database control over the cache mode for write operations is possible by opening the Database on the Replica and configuring the cache mode. Per-Cursor control (meaning per-record or per-operation) control of the cache mode is not possible on a Replica for write operations. For read operations, both per-Database and per-Cursor control is possible on the Replica, as described above.
The cache related stats in
EnvironmentStats can provide some measure
of the effectiveness of the cache mode choice.
|Enum Constant and Description|
The record's hotness is changed to "most recently used" by the operation.
The record's BIN (and its LNs) are evicted after the operation.
The record's LN is evicted after the operation, and the containing BIN is moved to the hot end of the LRU list.
The record's hotness or coldness is unchanged by the operation where this cache mode is specified.
|Modifier and Type||Method and Description|
Returns the enum constant of this type with the specified name.
Returns an array containing the constants of this enum type, in the order they are declared.
clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf
public static final CacheMode DEFAULT
More specifically, the BIN containing the record's LN is moved to the hot end of its LRU list.
This cache mode is used when the application does not need explicit control over the cache and a standard LRU approach is sufficient.
null may be specified to use the
public static final CacheMode KEEP_HOT
DEFAULTinstead. In an upcoming release this mode will function exactly as if
More specifically, the BIN containing the record's LN is moved to the hot end of its LRU list, and a best effort is made to keep the node from being evicted (assuming there is no subsequent access to this BIN using a different cache mode).
Use of this mode does not prevent a BIN from moving to the cold end of the LRU list as other nodes are moved to the hot end. The "best effort" referenced above consists of moving the BIN to the hot end when it reaches the cold end. However, to prevent overflowing the cache, if this node reaches the cold end again, before it is accessed again, it will then be evicted. This implies that for a record accessed with KEEP_HOT to be guaranteed to remain in cache while other records are also being accessed, it must be accessed fairly frequently.
This cache mode is normally used when the application intends to keep this record cached for as long as possible, even when it is not accessed frequently.
public static final CacheMode UNCHANGED
This cache mode is normally used when the application prefers that the operation should not perturb the cache, for example, when scanning over all records in a database.
public static final CacheMode MAKE_COLD
UNCHANGEDinstead. In an upcoming release this mode will function exactly as if
More specifically, if the cache is full, the record's LN and its
containing BIN are evicted according to the same rules as
EVICT_BIN. If the cache is not full or eviction of the BIN is
not possible, the BIN is moved to the cold end of the LRU list.
The reasons for using this cache mode are similar to those for using
UNCHANGED. The main difference between
this mode and
EVICT_BIN is that this mode does not cause
eviction until the cache is full. The main difference between this mode
UNCHANGED is that this mode evicts the BIN even when it was
loaded (and possibly made hot) by prior operations.
public static final CacheMode EVICT_LN
More specifically, when an operation is not performed via a cursor, the LN is evicted when the operation is complete. When a cursor is used, the LN is evicted when the cursor is moved to a different record or is closed. The BIN is moved to the hot end of the LRU in either case.
This cache mode is normally used when not all LNs will fit into the JE cache, and the application prefers to read the LN from the log file when the record is accessed again, rather than have it take up space in the JE cache and potentially cause expensive Java GC. By using this mode, the file system cache can be relied on for holding LNs, which complements the use of the JE cache to hold BINs and INs.
Note that using this mode for all operations will prevent the cache from filling, if all internal nodes fit in cache.
public static final CacheMode EVICT_BIN
This cache mode is normally used when not all BINs will fit into the JE cache, and the application prefers to read the LN and BIN from the log file when the record is accessed again, rather than have them take up space in the JE cache and potentially cause expensive Java GC.
Because this mode evicts all LNs in the BIN, even if they are "hot" from the perspective of a different accessor, this mode should be used with caution. One valid use case is where all accessors use this mode; in this case the cache mode might be set on a per-Database or per-Environment basis.
Note that using this mode for all operations will prevent the cache from filling, if all upper internal nodes fit in cache.
public static CacheMode values()
for (CacheMode c : CacheMode.values()) System.out.println(c);
Copyright (c) 2002, 2015 Oracle and/or its affiliates. All rights reserved.