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.
Currently, when a write is made, it will flush all service caches.
For example, a call to
elasticloadbalancing.DescribeTargetHealth
will cache, and a subsequent call toelasticloadbalancing.DeregisterTarget
(an non-cacheable write) would flush all caches underelasticloadbalancing
.This behavior might be inappropriate if the write is irrelevant to other reads.
In the above case for example, I do not want
DeregisterTargets
to flush all my caches forelasticloadbalancing
.This is further relevant when considering that
elb
andelbv2
are both using service nameelasticloadbalancing
.This PR adds a map of
mutatingCaches
which can define which write operations aremutating
and we should flush when they are called.By default, all writes are considered mutating (to have same behavior as now), however one could choose to exclude a specific operation from this behavior by using
SetCacheMutating(serviceName, operationName, false)
=> this will mark the specific operation as non-mutating.In this case we will only flush the operation cache i.e. discard that write cache instead of flushing all service caches
This can really improve cache hit/miss in some scenarios.