I see. The java doc is slightly misleading though. http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/CacheMode.html#UNCHANGED says "If the record was added to the cache by this operation, it will have "maximum coldness" and will therefore be colder than other records.". But, you are right. It does not make hard guarantees about when eviction will happen. I went through CursorImpl.performEviction as well to confirm.Yes, you're right. It will have maximum coldness, but it will still stick around in the cache for a while, until eviction happens naturally. This may be long enough to be promoted.
We already considered EVICT_LN (and even EVICT_BIN). Some background is that we are on SSDs with high memory churn. The problem is, it seems it will help different workloads to different extents in terms of earlier eviction. I am looking for a fool proof way that will make sure I can avoid GC entirely, since for all technical purposes, the cursor walk has nothing to do with normal workload. But, seems like this is not available.EVICT_LN is a good way to avoid GC, as much as is possible. You can specify EVICT_LN just for the cursor doing the scan, for a Database or the entire Environment. I know you have reservations, but I suggest trying it.
One final question :Is it possible to open another env handle (without closing already open env handle), with a non shared cache, for the cursor walk alone? Basic idea is to have a separate cache for the cursor walk alone. Is this doable at all. Please pardon, if my desperation shows >