CLIENT CACHING

Syntax

CLIENT CACHING <YES | NO>

Time complexity: O(1). Some options may introduce additional complexity.

ACL categories: @slow, @connection

Important: Only available when the RESP3 protocol is used.

The CLIENT CACHING command changes tracking of keys only for the next command executed by the connection.

When tracking is enabled using CLIENT TRACKING, it is possible to specify OPTIN or OPTOUT options, so that keys in read-only commands are not automatically remembered by the server to be invalidated later.

• When the client is in OPTIN mode, the standard behavior is to not track keys. The client can force tracking of the keys used in the next command by calling CLIENT CACHING YES before the command.
• Similarly, when the client is in OPTOUT mode, the standard behavior is to track keys. This behavior can be overridden for keys used in the next command by calling CLIENT CACHING NO before the command.

Again, the behavior change enforced by the CLIENT CACHING command is only applied to the next command.

Return

Simple string reply: OK if the argument is valid. An error is returned if RESP3 is not enabled, or the argument does not match the current tracking mode for the client. For example, if YES is specified when the mode is not OPTIN, or NO is specified when the mode is not OPTOUT.

Examples

# Set RESP3, which is required by client-side caching.
dragonfly> HELLO 3

dragonfly> CLIENT TRACKING ON OPTOUT
OK
dragonfly> SET user_count 100
OK

# The next command will not be cached.
dragonfly> CLIENT CACHING NO
OK
dragonfly> GET user_count
"100"

# Change client tracking mode.
dragonfly> CLIENT TRACKING ON OPTIN
OK

# The next command will be cached.
dragonfly> CLIENT CACHING YES
OK
dragonfly> GET user_count
"100"