I am new to valkey/redis and I have a question about the usage of MULTI command for transactions. Lets say we have a client with a single connection to valkey, and the client handles concurrent requests over this single connection, then if due to a request, if the client sends a MULTI request to valkey, then will the connection be in ‘Transaction Mode’ from this point on. And due to a concurrent request, if the client sends a command to valkey, will that be considered part of the transaction? How does such a scenario tie in with multi-threading in valkey (compared to Redis)
I have not tried anything yet, I want to understand the behaviour first
2
Answers
Different clients solve the problem in different ways, but generally one connection could only serve one thread if transactions are a requirement, unless special precautions are taken on the client sidea as threads would otherwise compete concurrently for the connection resource.
One option is to use locking (at the cost of performance, because other threads would have to wait until the transaction is complete).
Another option is to use connection pooling and use thread-per-connection patterns (this time at the cost of resources – as many active connections as there are active threads).
A third option is to do advanced multiplexing, such as with the StackExchange client for Redis (in this case at the cost of being able to do any of the blocking operations such as BLPOP / BRPOP / BRPOPLPUSH)
This topic is also highly dependent on how pipelining is achieved in the particular client and how data is processed.
Not saying from knowledge, but I’m almost sure at this point Valkey and Redis still behave the same in
MULTI
. Maybe in the next releases differences will be introduced, but I think it’s too soon for such difference.I guess your question is regarding standalone server?
Let’s distinguish between two concepts used with the same term –
As for connection, yes, if you start
multi
, all the commands the client connection send are sent as part of themulti
. If other connections send commands, they won’t be served until themulti
ends.That’s what
multi
is trying to guarantee, some kind of atomic behavior, all happens together and nothing else.At this point comes the need for management, which is why client libraries exist.
At ValKey-Glide we use multiplexing connection, as the third option mentioned in the prev answer.
That means, in simple words, that all the commands you want for the
multi
will be aggregated and will be sent together. Meaning you have plenty of commands in flight, themulti
commands count as one all together, and it lands at the server as one.It’s important to emphasize that if you decide to use multi, it means that you want to have a strict order of commands, so it’s not supposed to be a friend of multithreading.
So the multiplexer behavior makes sense — you get the best of the resources, but you don’t break the logic when you require it. But, as mentioned, if you would like to use blocking commands in the multi, you should have another multiplexer; otherwise, it will stay blocked forever.
Did you mean to ask about multithreaded server?