How does the
setUseGrvCache flag affects performance? Can it allow for stale reads to happen under slightly loaded cluster?
I have the impression that with this cache, the grv is cached at the (native) client level, so any commits that may happen during a read tx may result in a stale read, but I didn’t manage to exhibit this behaviour.
Also, for this case of stale reads on a readonly transaction, I guess the tx can be safely retried (either hoping for the grv cache to update, or retried with grv cache skip to force a refresh)?