Does CCF support batching of client transactions?

[Prakash Narayana Moorthy (prakashngit)]

Is there a plan to add clien-side support a submit an rpc that consists of transaction-batch? Please forgive me If this is already supported, kindly point me to an example.

[Amaury Chamayou (achamayou)]

This was discussed in the past, but there is currently no plan or design for this. Can I ask you what the motivation for this batching is?

If it's atomicity, I'm afraid that's impossible to guarantee outside one transaction at quite a fundamental level.

If it's transport efficiency/amortizing transport costs, it may be worth exploring the following avenues:

1. Pipelining, clients need not wait for an answer to send the next request. Our performance test client typically allows 1000 requests to be outstanding before it backs off.
2. Websockets, which reduces the size of the frame considerably, and can be pipelined too.

We are of course happy to discuss and consider alternatives :)

[Prakash Narayana Moorthy (prakashngit)]

Amaury Chamayou (@achamayou) Thank you for the notes. It was not for atomicity. Like you say it was aimed at transport efficiency. The reason why I asked was I guess I saw in the code that batching was an option internally within CCF while performing consensus? May-be, I am mistaken. I was just wondering if that parameter could be exposed to the app user as well. Thank you for the suggestions. Yes, suitable pipelining seems a good option will consider that.

Aside: I know that Hyperledger Sawtooth permits batching of transactions, and while submitting the batch, the user can even specify intra-dependency within a batch to ensure expected serialization.

Thank you once again!

[Alex Shamis (ashamis)]

CCF has session consistency for requests submitted by the same TLS session. However, the guarantee that we provide is if tx_a is submitted before tx_b over the same TLS connection tx_b will be executed after tx_a has completed running. However, the execution of tx_b is not bounded on the final result of the execution of tx_a.

As the code currently standing if you need to enforce a dependency between txs that is not provided by CCF. However, as Amaury Chamayou (@achamayou) mentioned happy to discuss.

[Amaury Chamayou (achamayou)]

We've discussed enabling optimistic concurrency control before via ETags, but it is not currently implemented #1524

[Amaury Chamayou (achamayou)]

ETag support was added in #6110 along with documentation showing how to use it and is now leverage by the built-in ledger chunk download API #7652.