Fixed hot cache update on calls to Set() #11
Merged
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.
Purpose
@xWiiLLz Reported the hot cache's of remote peers were not updated when calling
Set()
. mailgun/groupcache#69This PR fixes a long standing TODO where there was some question if the hot cache should always be updated on calls to
Set()
.Resolution
We should ALWAYS update the main cache and delete the key from the hot cache when
Set()
is called.Rationale
We do not know when the owning peer may switch to a different node due to cluster topography changes. If an owner belongs to a different node the instant after
Set()
completes, calls toGet()
, consulting the hot cache, may find the previously set value.Because we don't know which or when a node in the cluster may become the owner, every node in the cluster should be treated identically.
I left the
hotCache
boolean in the signature ofSet()
as I didn't want to make a version breaking change.