[NEW] The ability to check the optimistic lock before starting a transaction

[bozaro]

The problem/use-case that the feature addresses

As far as I know, there are currently two options for implementing optimistic locks for non-trivial changes: WATCH/MULTI/EXEC and LUA.

LUA functions look like a rather expensive solution in terms of CPU.

WATCH is actually incompatible with clients that use pipelining instead of a connection pool: a round trip is required between WATCH and MULTI to make decisions on the client side.

Description of the feature

Instead of WATCH, make it possible to explicitly specify the version condition in the optimistic lock for MULTI.

For example, instead of:

WATCH mykey
val = GET mykey
val = val + 1

MULTI
SET mykey $val
EXEC

Make a construction of the form:

old = GET mykey
new = old + 1

MULTI CHECK mykey EQ $old
SET mykey $new
EXEC

Alternatives you've considered

For trivial cases, it is possible to use SET+IFEQ/NX/XX/INCR/etc, but if you need to change several keys or HSET, then optimistic locking can only be done using LUA.

Additional information

There has already been a similar discussion in PR:

• [NEW] MULTI Idempotency Keys for safely retrying non-idempotent commands #1087
• [NEW] Support Check and Set functionality #1215 (comment)

[dvkashapov]

Seems like #1215 solves this issue for single/multiple keys. MULTI/EXEC has no guarantees around execution of every command or even part of them so I'd suggest using SET IFEQ.

HSET is another story though, what usecase do you have in mind?

[bozaro]

Seems like #1215 solves this issue for single/multiple keys. MULTI/EXEC has no guarantees around execution of every command or even part of them so I'd suggest using SET IFEQ.

HSET is another story though, what usecase do you have in mind?

SET IFEQ solves the problem if exactly one key needs to be changed. Moreover, the value is a string.

If you need to change multiple keys on one shard, it becomes useless.

I tried to make a construction like:

old = GET ver{foo}
new = old + 1

MULTI
SET ver{foo} $new IFEQ $old
SET mykey{foo}1 111
SET mykey{foo}2 222
EXEC

and SET mykey... is executed even if SET ver{foo} failed on compare (which corresponds to the documentation).

The solution with WATCH should help in theory:

WATCH ver{foo}
old = GET ver{foo}
new = old + 1

MULTI
SET ver{foo} $new IFEQ $old
SET mykey{foo}1 111
SET mykey{foo}2 222
EXEC

but for this you need to replace pipelining with a connection pool. I expect more performance problems from this than potential benefits.