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