WATCH to mark keys whose modification should cancel the next transaction, which gives you optimistic locking.
If any watched key is changed by another client between the WATCH and the EXEC, the transaction is not executed and EXEC replies with null instead. Nothing is locked in the meantime: other clients keep working normally, and the conflict is detected rather than prevented.
The usual loop is: watch the keys, read them, decide what to write, open MULTI, queue the writes, and call EXEC, retrying from the top when the reply is null. That is how a read-modify-write cycle stays correct without holding a lock. All watches are cleared by EXEC and DISCARD.
The raw command is TCP-only. Over HTTP, use the transaction or pipeline API of an Upstash SDK instead of sending this command directly.
Syntax
Arguments
Important points
- The raw command is TCP-only. For HTTP, use an Upstash SDK transaction API rather than sending this command directly.
Response
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples
TCP examples use the TLSREDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.
Redis CLI
Redis CLI
ioredis
ioredis
node-redis
node-redis
redis-py
redis-py
go-redis
go-redis
jedis
jedis
redis-rs
redis-rs