cache values and errors, not futures #81
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@bbakerman can I get some initial thoughts on this before I push further with testing and other code cleanup/refactor? |
craig-day
commented
May 5, 2021
Comment on lines
+566
to
+570
| if (!valueCache.containsKey(cacheKey)) { | ||
| valueCache.set(cacheKey, error); | ||
| } |
There was a problem hiding this comment.
The more I look at this, the more I'm not sure if it's right. Initially, I changed the CacheMap#get function to return a Try to allow priming the cache with an error, but I'm wondering if that is right. Maybe we just keep an independent cache of errors to support priming failures, but not let the CacheMap worry about that. That makes a lot more sense to me than caching errors, which are often times much more temporary than a cache would be.
|
I see the problems now around caching futures vs. values. I'm closing this for now until I come up with a better idea. |
|
Alternative approach in #82 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I believe this fixes #59 by explicitly caching values, not completed futures, and it implicitly fixes #45 because the signature becomes correct with this change.
I don't think there is a way to do this in a non-breaking fashion, but I still think it's worth doing for the next release. Since I'm in here breaking things, one question I have is why do we use
Objecteverywhere for the cache key. Can we instead change the signature ofCacheMap<K, V>to beCacheMap<V>and then have the functions look likeget(CacheKey key)andset(CacheKey key, V value)?On the breaking note, I changed the error state to use
Throwablebecause it's more common and generic. It also plays nicer with converting to/fromCompletableFuture.I also switched the default implementation to use a
ConcurrentHashMapwhich can help avoid somesynchronizedcalls and eliminate the chance of colliding cache operations.In addition, I added a quality-of-life function,computeIfAbsent, but I'm happy to remove that from this PR if we think it's out of scope.