Skip to content

Commit 7a2d569

Browse files
committed
wording
Signed-off-by: Attila Mészáros <[email protected]>
1 parent 1ff9952 commit 7a2d569

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/content/en/blog/news/primary-cache-for-next-recon.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,7 @@ The trick is to cache the resource from the response of our update in an additio
5959
cache. If we read the resource, we first check if it is in the overlay cache and read it from there if present,
6060
otherwise read it from the cache of the informer. If the informer receives an event with a fresh resource, we always
6161
remove the resource from the overlay
62-
cache, since that is a more recent resource. But this **works only** if the update is done **with optimistic locking**.
62+
cache, since that is a more recent resource. But this **works only** if our request update is using **with optimistic locking**.
6363
So if the update fails on conflict, we simply wait and poll the informer cache until there is a new resource version,
6464
and try to update again using the new resource (applied our changes again) with optimistic locking.
6565

0 commit comments

Comments
 (0)