RemovalCause

[joanbalaguero]

Hi Ben,

In my use case, when an entry is expired or explicity removed, under certain conditions I must recache it by calling a supplier api. But this must not be perfomed in case of a clear ("invalidateAll()").

So I was wondering if it would be possible to create a new RemovalCause, something like CLEAR, which is also EXPLICIT (it would be like SIZE, which is also an eviction like EXPIRED).

EXPLICIT {
public boolean wasEvicted() {
return false;
}
public boolean wasExplicit() {
return true;
}
},
CLEAR {
public boolean wasEvicted() {
return false;
}
public boolean wasExplicit() {
return true;
}
},

So if the removal listener receives a CLEAR for an entry, I will not recache it.

Thanks,

Joan.

[ben-manes]

Have you looked into whether refreshing would be a fit instead? This asynchronously reloads the entry, either by an explicit call (LoadingCache#refresh) or if accessed after a duration (refreshAfterWrite). The examples dir has a contribution showing how to coalesce multiple reloads into a batch call for efficiency.

[joanbalaguero]

Hi Ben,

Refreshing entries is not a solution in our case, getting new entries must be done by querying external resources as apis, ... it's not a kind of MapStore. We have tried to solve this programatically, but our fix is not good enough ... that's why I was asking how complicated would be to add this new RemovalCause category ... not sure if you see this useful in general, not only for my use case.

I will ask you another question in a new post.

Thanks,

Joan.

[ben-manes]

I am hesitant to add another category as some will have hard coded against the enum options, its behavioral versus operation-based, and this sounds like the wrong solution to the problem. If the entry was removed but now needs to be reloaded, then the removal was premature and there may be a design flaw. Solr tried this as a simple workaround rather than fixing their design, but it incurred a performance penalty because it increases their code's lock contention. In their case the preferred approach is to use pinning to exclude the entry from being eligible for eviction or provide a similar mechanism (their "overflow cache").

I'd be happy to help you by digging more into your use-case, but I'd be steering you towards a different solution than your proposal.