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 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:

When passivation is disabled:

            1) RAM: /A Disk: /A
            2) RAM: /A, /B Disk: /A, /B
            3) RAM: /B Disk: /A, /B
            4) RAM: /A, /B Disk: /A, /B
            5) RAM: /A Disk: /A, /B
            6) RAM: /A Disk: /A
         

When passivation is enabled:

            1) RAM: /A Disk:
            2) RAM: /A, /B Disk:
            3) RAM: /B Disk: /A
            4) RAM: /A, /B Disk:
            5) RAM: /A Disk: /B
            6) RAM: /A Disk: