Named caches provide a mechanism to control the amount of memory used to cache managed objects. Named caches can be dynamically defined, and managed objects added, at runtime without impacting a running application. Named caches support configurable cache policies and support for automatic, and explicit managed object flushing.
The default caching policies for managed objects when they are not associated with a named cache are:
Distributed objects (see Chapter 6, Distributed computing) are never cached.
Replica objects (see Chapter 7, High availability) are always cached, and cannot be flushed.
Named caches are defined using an API or administrative commands.
Named caches support these cache policies:
Always - object data is always accessed from shared memory on the local node. These objects are never flushed from shared memory.
Never - object data is never accessed from shared memory on the local node. These objects are always flushed from shared memory. This cache policy is defined by setting the cache size to zero.
Sized - object data is always accessed from shared memory on the local node. These objects are automatically flushed from shared memory when they exceed a configurable maximum memory consumption size.
Cache policies are specified per named cache and they can be dynamically changed at runtime.
The implications of caching a distributed object are described in the section called “Reading and writing object fields”.
Managed objects are associated with a named cache by class name at runtime. When a class is associated with a named cache all objects of that type are moved into the cache, along with any objects that extend the parent class, that are not already associated with a cache.
Named caches support inheritance. If a class is associated with a named cache all objects with that class as their parent are moved into the named cache. If another named cache is defined and a child class of the parent is associated with it, only the child objects (and any of it's children) are moved into the named cache. All other objects are left in the parent's named cache.
All managed objects, except for replica objects, can be flushed from shared memory.
Cached objects are flushed from shared memory:
explicitly using an API.
automatically at the end of the current transaction (only distributed objects not in a named cache).
using a background flusher when associated with a named cache.
Regardless of how an object is flushed, it has this behavior:
flushing a local managed object, including partitioned objects on the active node, is equivalent to deleting the object, any installed delete triggers will be executed.
flushing a distributed object removes the object data, including any key data, from local shared memory.
flushing a replica object is a no-op. Replica objects cannot be flushed since that would break the redundancy guarantee made in the partition definition.
Figure 4.1, “Object refresh” shows how a distributed
object is refreshed after it was flushed from memory.
O1` is a distributed reference to
O1 that was stored in an object field on
Node One. Accessing the field containing the
O1` distributed reference on Node
will cause the object data to be
refreshed from OneNode. Two
Distributed objects not in a named cache are automatically flushed from shared memory at the end of the transaction in which they were accessed. These objects are never in shared memory longer than a single transaction.
A background flusher evicts objects from shared memory in named caches. Objects are flushed from shared memory when the total bytes in shared memory exceeds the configured maximum size. Objects are flushed from shared memory using a Least Recently Used algorithm. The background flusher operates asynchronously, so the maximum memory utilization may be temporarily exceeded.
Objects are also automatically flushed from shared memory when memory throttling is in affect, for example when a distributed query fetches a large number of remote objects that cause local cache limits to be exceeded.
When calculating the size of shared memory required for a node, cached objects must be included in the sizing. See the ActiveSpaces® Transactions Sizing Guide.
Optionally a flush notifier can be installed by applications to control whether an object is flushed or not. When a flush notifier is installed it is called in the same transaction in which the flush occurs. The notifier is passed the object that is being flushed, and the notifier can either accept the flush, or reject it. If the notifier rejects the flush the object is not flushed from shared memory. The flush notifier is called no matter how an object flush was initiated.