addthis / basis Goto Github PK

MediatedEvictionConcurrentHashMap is fork of ConcurrentLinkedHashMap v1.3 to provide more control over which victim is selected for eviction. If an entry is currently in use, e.g. locked as part of a transaction, then it is not eligible and the cache should find another candidate. The mediator helps coordinate in a state machine, as well as provide a synchronous hook for persisting the evicted entry.

ConcurrentLinkedHashMap is being replaced by Caffeine, so I'd like to see if the features of that library would serve your purpose. If so, then it provides an upgrade path and will allow you to not maintain a fork.

The challenge with mediation as a feature in a generic cache is that in the worst case it is O(n) and perhaps no candidate is available. That breaks the contract and, while perhaps a user error, is not a good API design for general purpose. This is evident by Ehcache's EvictionVeto which tries to serve this case. However, if all (8) evaluated entries are vetoed then Ehcache evicts a non-eligible entry anyways, though this is not documented and may lead to surprising behavior.

An alternative idea might be to model this using weights. An entry with a weight of 0 is not size-based evicted and does not count towards the cache's maximum size. The cache can still find a victim to remove by skipping these entries, so its functionality is correct. The caveat that those entries don't count towards eviction may lead to an overall greater cache size, as the mediated cache might find a victim in the common case. It also requires a write into the cache to modify the entry's state (via compute), which is slower than atomically toggling a flag in the entry itself. However, when combined with a CacheWriter for a synchronous hook with eviction, it would serve the purpose Hydra needs.

Thoughts?