API proposal : pooled / leased connections as a secondary API

Motivations:

• provide safe access to blocking operations (BRPOPLPUSH, etc)
• provide "pure" access to WATCH/MULTI/EXEC
• we already expose the user to the risk of these operations via Execute; this would hopefully stop people doing dangerous things on the main connections

Counter-motivations:

• Lua scripts are better solutions for most (but not all) scenarios that previously would have been WATCH/MULTI/EXEC

Note:

If implemented (needs consideration), the multiplexer would take care of the socket IO, but they would be stored separately and would not participate in the multiplexed command stream. This would be in addition to the regular API and would just work inside the existing context.

Questions:

• what does this mean for cluster? is it assumed that all operations on a lease will participate on a single shard and will therefore be single-server?
• how is primary/replica selected
• what does the lease API look like - presumably using?
• what happens when the pool is exhausted? is it an "await (async) an item from the pool, or timeout after x"?
• where would it attach; IServer ? and if so, do we need a new GetServer mechanism that makes this painless?
• how complex does the pool management need to be? just a max? is it enabled at all if not configured?
• do timeouts apply on blocking operations? if so, how?

Timescales:

It won't be 2.0

Likelihood:

Thinking about it; it is tempting.

Start by reviewing the existing Execute and IServer APIs, then consider how a separate leased-connection API would fit alongside the regular API. The open questions cover cluster behavior, primary/replica selection, lease syntax, pool exhaustion, configuration, and timeouts; done requires an agreed design for these concerns.