Cache Loader behavior with and without passivation
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 backend store via the cache loader. There is no direct relationship between eviction and cache loading. If you don't 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 entries 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 keyOne 2. Insert keyTwo 3. Eviction thread runs, evicts keyOne 4. Read keyOne 5. Eviction thread runs, evicts keyTwo 6. Remove keyTwo  When passivation is disabled: 1) Memory: keyOne Disk: keyOne 2) Memory: keyOne, keyTwo Disk: keyOne, keyTwo 3) Memory: keyTwo Disk: keyOne, keyTwo 4) Memory: keyOne, keyTwo Disk: keyOne, keyTwo 5) Memory: keyOne Disk: keyOne, keyTwo 6) Memory: keyOne Disk: keyOne  When passivation is enabled: 1) Memory: keyOne Disk: 2) Memory: keyOne, keyTwo Disk: 3) Memory: keyTwo Disk: keyOne 4) Memory: keyOne, keyTwo Disk: 5) Memory: keyOne Disk: keyTwo 6) Memory: keyOne Disk: