Musings about cache invalidation and naming things
They say that the two most difficult things in software development are cache invalidation and naming things. Then perhaps the most difficult thing in all of software development is naming things in a cache, something I’ve had recent experience with.
I’m working on a currency conversion program that uses the free tier of Manny’s currency conversion API. So like, for example, my program needs to know the conversion of dollars to euros, it sends Manny’s API the query “USD_EUR” and the API responds with something like 0.92 or whatever the conversion rate happens to be.
Although the free tier of that API is fairly generous, I don’t want to overburden it by having my program repeatedly ask for rates my program could just cache. This seems like a perfect use case for a least recently used (LRU) cache.
But when should cached rates be invalidated? A rate from a minute ago, for example, should still be good, and in any case I would not expect the free tier of a conversion API to update that frequently anyway. But a rate from more than 24 hours ago is most likely stale.
So I wrote a stub for a procedure called invalidate(), which I would flesh out through the process of test-driven development (TDD).
As I thought about the Javadoc I would eventually write, I was thinking I would write that “refresh is the default behavior of this procedure.”
That led me to realize that this procedure I was about to write should in fact not be called invalidate() but instead refresh().
It is important to distinguish between cache invalidation strategies and cache invalidation methods. Invalidation strategies determine when an item in a cache is stale. Invalidation methods dictate how exactly a value is going to be removed from the cache once it has been determined to be stale.
The two broad categories of invalidation methods are refresh and purge. To refresh means to obtain the item anew, such as from a database or from an online API, replacing the stale value. To purge means to delete the item from the cache altogether.
In the case of cached currency conversion rates, refresh makes more sense, at least for the most commonly traded currencies, such as U. S. dollars and euros, which will likely continue to exist despite political instability in the United States or the European Union.
Because I was working on this in an integrated development environment (IDE) and it hasn’t been released for general use yet, renaming invalidate() to refresh() was easy.
And also because I was programming the LRU cache from scratch, rather than using an existing proprietary class like sun.misc.LRUCache<N, V>.
That class has an eviction policy, but it doesn’t provide any mechanism for cache invalidation. Even so, its author, Mark Reinhold, must have felt the pressure of coming up with the perfect names for things.
For the most part, he made good decisions. I don’t question the naming of the functions create() or hasName(), nor of the procedure moveToFront(). Those are perfectly clear and obvious.
I do question the naming of forName(), because it includes a reserved word of the Java programming language and it repeats the name of a parameter, name, though with different capitalization (I’m quite okay with paintComponent() in Java Swing including “int,” however).
What forName() does is that it takes a name parameter and returns a value corresponding to that name. If the name-value pair is not already in the cache, it calls create(), otherwise it retrieves the cached value.
Reworking the LRU cache for my own purposes, I decided to call that function retrieve() instead. But that’s misleading, because that’ll involve a create() call for the very first time a given name is called for (and obviously also if the name-value pair was in the cache but was subsequently evicted for being the least recent).
Do you have any thoughts of what would be a better name for forName()? Please let me know in the comments.