FWD » Core Development » Database

FastFindCache currently reacts to writes by invalidating cached results very aggressively. In a workload where the same index entries are repeatedly invalidated and then immediately queried again, this creates a thrashing pattern:
- the cache entry is cleared,
- the next lookup repopulates it,
- another update clears it again,
- and the cycle repeats.
This means the cache is spending effort on entries that may not stay valid long enough to pay for the cost of caching them. The result is extra invalidation traffic, extra repopulation work, and limited real benefit for very hot keys.

A practical fix is a 2-hit admission policy:
- do not cache an entry the first time it is requested,
- only admit it into FastFindCache if the same key is requested again soon after.

The challenge here is to efficiently remember when a key was already requested for caching, if this can be achieved, the benefit would be an overall more efficient ffc.

The initial implementation shows promise, these are the results of comparing memory retention of FFC, trunk vs 11638a:
multi tenant app harness + 1 user creation: 2.2mb -> 0.6mb, 3.6x less retained memory
large gui app unit tests: 9.9mb -> 1.3mb, 7.5x less retained memory

The performance is not reduced since we are no longer caching results that were not hit anyway.

The main parts of the implementation are:
- The first time a key is seen, it is stored in a small probation structure keyed by the same cache key components already used by FastFind, so we can recognize the exact same lookup later.
- On the second sighting within the probation window, the entry is admitted into the main cache and stored normally.
- The probation state has a bounded lifetime and size, it uses a short TTL window, currently 1 minute, and a small LRU cache so it does not grow without limit.
- Invalidation paths now also clear the probation state for the affected table or index, so stale "seen once" keys do not linger after writes.
- The policy applies before the main cache write, so it helps both positive hits and negative results avoid immediate cache tharshing.

I am tidying up the code and will request a review. Any suggestions are welcomed.