9.4. Cache Passivation

A cache loader can be used to enforce node passivation and activation on eviction in a cache.
Cache Passivation is the process of removing an object from in-memory cache and writing it to a secondary data store (e.g., file system, database) on eviction. Cache Activation is the process of restoring an object from the data store into the in-memory cache when it's needed to be used. In both cases, the configured cache loader will be used to read from the data store and write to the data store.
When an eviction policy in effect evicts a node from the cache, if passivation is enabled, a notification that the node is being passivated will be emitted to the cache listeners and the node and its children will be stored in the cache loader store. When a user attempts to retrieve a node that was evicted earlier, the node is loaded (lazy loaded) from the cache loader store into memory. When the node and its children have been loaded, they're removed from the cache loader and a notification is emitted to the cache listeners that the node has been activated.
To enable cache passivation/activation, you can set passivation to true. The default is false . When passivation is used, only the first cache loader configured is used and all others are ignored.

9.4.1. Cache Loader Behavior with Passivation Disabled vs. Enabled

When passivation is disabled, whenever an element is modified, added or removed, then that modification is persisted in the back end store via the cache loader. There is no direct relationship between eviction and cache loading. If you do not use eviction, what's in the persistent store is basically a copy of what's in memory. If you do use eviction, what's in the persistent store is basically a superset of what's in memory (i.e. it includes nodes that have been evicted from memory).
When passivation is enabled, there is a direct relationship between eviction and the cache loader. Writes to the persistent store via the cache loader only occur as part of the eviction process. Data is deleted from the persistent store when the application reads it back into memory. In this case, what's in memory and what's in the persistent store are two subsets of the total information set, with no intersection between the subsets.
Following is a simple example, showing what state is in RAM and in the persistent store after each step of a 6 step process:
  1. Insert /A
  2. Insert /B
  3. Eviction thread runs, evicts /A
  4. Read /A
  5. Eviction thread runs, evicts /B
  6. Remove /B
When passivation is disabled: 
                1) Memory: /A Disk: /A
                2) Memory: /A, /B Disk: /A, /B
                3) Memory: /B Disk: /A, /B
                4) Memory: /A, /B Disk: /A, /B
                5) Memory: /A Disk: /A, /B
                6) Memory: /A Disk: /A
When passivation is enabled: 
                1) Memory: /A Disk:
                2) Memory: /A, /B Disk:
                3) Memory: /B Disk: /A
                4) Memory: /A, /B Disk:
                5) Memory: /A Disk: /B
                6) Memory: /A Disk: