Cache Loader behavior with and without passivation

WARNING - TOPIC NOT WRITTEN - TOPIC ID: 1564

This topic has not yet been written. The content below is from the topic description.
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: