That angle seems potentially insightful, and I'm going to have to think about it, but to me, cache invalidation seems more like replacing one logical thing with nothing. It may or may not get replaced with a new version of the same logical thing later if that's required.

▲

cluckindan a day ago | parent [-]

To me, cache invalidation is not strictly about either replacing or removing cache entries.

Rather, cache invalidation is the process of determining which cache entries are stale and need to be replaced/removed.

It gets hairy when determining that depends on users, user group memberships AND per-user permissions, access TTL, multiple types of timestamps and/or revision numbering, and especially when the cache entries are composite as in contain data from multiple database entities, where some are e.g. representing a hierarchy and may not even have direct entity relationships with the cached data.

▲

kragen a day ago | parent [-]

Yes—and, in many cases, ensuring that you don't use entries which become outdated during your computation.

▲

cluckindan a day ago | parent [-]

A bit of TOCTOU sprinkled in the cache integration ensures a fun day at the races!

▲

kragen a day ago | parent [-]

TOCTOU bugs are a subset of cache invalidation bugs.

	▲	cluckindan 15 hours ago \| parent [-]
		Are they really? TOCTOU is a trigger for race conditions, but I guess the result of the check is a cached value. Then again, the issue in TOCTOU is that the ”cached value” is not invalidated at all, or inadequately. It doesn’t really have anything to do with the invalidation mechanism, it is downstream from it.