Open up parts of the API

Feature Request

I’m working on a Scala wrapper of your library that brings two key features: 1.) easier Scala interoperability 2.) thread-safety across transactions

In order to achieve the latter, whenever someone calls multi, I’m essentially doing something like 1.) return a new object that from the outside looks like it’s a redis client, but is actually a wrapper around the current client 2.) all methods (other than exec) that get called, create a Command and push it to a queue 3.) once exec is called: take out a shared lock, send the server a multi, followed by all the commands in the queue, followed by exec, and release the lock 4.) this wrapper may not be used again

I implemented it and it all works just fine, but I had to do something ugly: for a few classes, I had to declare them inside of a package io.lettuce.core so that I could access some internals. This included: a.) CommandArgs.singularArguments, in order to access all the keys in a command. Used to find the slot/underlying connection to use if running in cluster mode. b.) BaseRedisAsyncCommands.dispatch, in order to dispatch the queued commands c.) RedisCommandBuilder, to create Commands to dispatch

Is my goal to create a thread-safe transactional API reasonable? Would you go about it different? Would you consider opening up the visibility of some of these APIs, or do you have any suggestions about how I could implement it differently?

Is your feature request related to a problem? Please describe

My project runs in a highly parallel environment, and the lack of thread safety in the multi API is very cumbersome.

Describe the solution you’d like

Opening up parts of the API to make extending it easier.

Describe alternatives you’ve considered

Haven’t been able to think of much.

Teachability, Documentation, Adoption, Migration Strategy

This change wouldn’t really have much impact on existing users.

[mp911de]

Would it be easier to add an overload that just uses the old behavior?

Then we re-introduce the error-prone behavior without helping users to understand why they potentially run into issues.

https://github.com/lettuce-io/lettuce-core/issues/1311#issuecomment-660942403 isn’t really saying that I’m avoiding complexity, it’s more outlining what we can/should do.

[dontgitit]

fair enough! FWIW we’ve been using the version with the ReadWriteLock and it’s been working well enough