ClusterClient: no way to execute transaction without WATCH/UNWATCH

[flyingmutant]

Regular Client has Watch(), which is doing MULTI/EXEC (no WATCH/UNWATCH) when no keys are specified.

This behaviour is impossible to obtain using ClusterClient: you have to specify at least 1 key (so that master node can be selected), but you have no way to avoid passing it to Client.Watch. Thus, every transaction is wrapped in WATCH/UNWATCH pair.

Workaround (use a bogus random key with the hash slot you want) is not very elegant.

[vmihailenco]

Why you are not using Pipeline? AFAIK it is the same as Tx without Watch.

[flyingmutant]

I haven't tried it — but looking at ClusterClient.pipelineExec() / ClusterClient.execClusterCmds(), I don't see MULTI/EXEC wrapper anywhere. Am I missing anything?

[vmihailenco]

It does not, but AFAIK it does not matter much. Redis is single threaded so commands batched together with Pipeline will be executed without interruptions, which is the same as executing them with multi/exec.

[flyingmutant]

Can you please point me to the place in the code where MULTI/EXEC is applied, for non-transactional pipelines? I can only see it in tx.go.

I think you are wrong about pipelines guaranteeing atomic execution. There are no «start pipeline»/«end pipeline» markers, so redis can not provide such guarantee (imagine what will happen if your pipeline is split between many TCP packets?). Pipelining is a network optimisation, and nothing more.

[vmihailenco]

There was a typo in my previous my message "it does" -> "it does not" :) Anyway I will try to find a way to not require keys, but I don't see any atm.

imagine what will happen if your pipeline is split between many TCP packets

I don't insist, but I believe that in practice it is not possible that Redis Server can receive and process batched commands in parts. I don't know much about TCP, but I think different packets are merged together before data arrives to Redis.

[flyingmutant]

Would you accept a PR which adds something like ClusterClient.MasterNodeForKey(key string)?

[vmihailenco]

I am not sure. Why instead of cluster.MasterNodeForKey(key string).Watch(fn) not to use cluster.Watch(fn, key)? How the former is better?

[flyingmutant]

cluster.Watch(fn, key) always passes key to slotMasterNode.Watch(fn, key), which is what I want to avoid. It can be possible to add another cluster.Watch() variant, but it does not look very elegant.

The best thing would be to expose redis transactions as a first-class API, and not something hidden behind Watch special-case. But that is a much more invasive change.

[bmarini]

The best thing would be to expose redis transactions as a first-class API, and not something hidden behind Watch special-case. But that is a much more invasive change.

Agreed. Also I would prefer the regular client expose redis transactions in a more obvious way too. The fact that you must use Watch() with no watched keys to create a normal "MULTI ... EXEC" transaction is not clear.

[vmihailenco]

I like the idea. I already added TxPipeline to normal Client - #444. ClusterClient requires much more work though...

[vmihailenco]

Should be possible now using TxPipeline, which works just like Pipeline, but wrap commads with Multi/Exec.