I would like to do a basic watch with StackExchange.Redis. Where if a key is changed during the transaction, it fails.
StackExchange.Redis has abstracted this nicely
The reason WATCH
isn't exposed directly is because of how SE.Redis is designed to multiplex commands from different call stacks on a single connection. This makes it necessary for any transaction work to be very tightly managed.
I am unclear of quite what the purpose of "unchanged" would be by itself, without comparison to some known value - otherwise you're just creating a race condition. It would definitely be possible to add support for it, but I'd really like to understand the expected use-case first. Can you explain?
Re your edit; your preferred example (the last one) simply isn't possible with redis - nothing to do with SE.Redis; if you do a GET
inside a MULTI
, you don't get the answer until the EXEC
completes - so you can't possibly use the value in the SET
: it isn't available yet.
If it wasn't for multiplexing, you could re-order your second example (based on what SE.Redis does) a bit:
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
this is the typical use of WATCH
: you watch the things that you're querying in advance, then you know that {key}
is unchanged during this loop (or at least, the transaction will have aborted; no inconsistent state). However, WATCH
does not play well with a multiplexer, which is why SE.Redis forces you down the route of fetching the value in advance of the transaction, then allowing you to compare the value to assert that it is unchanged. Same result; slightly different approach, but it is multiplexer-safe. For more on that topic see here.