multi() support without requiring external synchronization

[Brian1KB]

Feature Request

The ability to use multi() or some variant of it without needing to provide external synchronization

Is your feature request related to a problem? Please describe

I have a heavily multi threaded application where I use a single Lettuce connection. Previously, I used Jedis with an Apache Commons GenericObjectPool, and since migrating I've had great performance improvements, and everything is playing nicely with virtual threads. However, I need to use multi(), which means I'll need to either:

A. Synchronize the single connection, however this would result in blocking further commands from being added to the pipeline until the multi/exec is complete

B. Involve a connection pool as mentioned on the wiki, which would result in an increase in complexity, and an increase in latency in instances where new connections to the Redis must be instantiated.

Describe the solution you'd like

Rather than the multi command instantly being added to the command queue, I believe (without understanding the internals involved very well mind you!) that it would make more sense for there to be an additional multi command which would instead return a RedisCommands<K, V> instance itself. Then, you could run your commands on this, and only when you run exec() here would the multi, commands & exec be appended on to the queue on the "true" RedisCommands instance.

Perhaps this is not possible as a result of some technical restriction, but if so I'd love to hear why from someone with a bit more knowledge. Many thanks.

Describe alternatives you've considered

N/a

Teachability, Documentation, Adoption, Migration Strategy

N/a

[tishun]

From an API perspective there are multiple ways where we could wrap the commands together.
So this part is not a challenge itself.

The problem comes when we decide to flush them to the wire. Lettuce is an async thread-safe driver, which means that a multitude of threads could be sending out commands. All of them end up with a call to Netty that provides the command and a callback for the result.

On the other side there is an event loop that goes through the list of pending commands and executes them one after another. However the order is inherently not guaranteed, as the event loop does not control the order the threads send out their commands.

If we decide that one thread needs to use the communication channel exclusively we essentially have to block all other threads from writing to it, because they would otherwise pollute the transaction (inserting their commands inside it).

Conceptually speaking this would go against the core idea of the driver to be non-blocking and could reduce the performance drastically. It is not unsound to require a separate channel for threads that require transactions, as transactions are more demanding.

Hope that makes sense. I am open to suggestions, as usual, as there might be some solution I've not considered.

[tishun]

Having spent some time thinking about this I think it might be possible to achieve it, with some changes to the API.

However it is a disruptive change and it would require some time to prepare it.
It would also require extensive testing to verify we are not introducing a regression

Let's continue monitoring this in #3084