[server-dev] Re: [RFC] Interactive transactions in IProto

[Vladimir Davydov]

On Tue, Nov 13, 2018 at 08:51:40PM +0300, Vladimir Davydov wrote:
>  - Generating transaction_id on the server and returning it back to the
>    client would look rather ugly when it comes to implementing net_box
>    client, because we would have to add extra return parameters to
>    net.box 'call' method, which isn't very convenient. Compare with
>    streams where the user gets a stream object that behaves exactly like
>    a connection, but guarantees sequential execution and transaction
>    preservation.

OTOH we could introduce the notion of streams in net.box using
transaction_id internally, i.e. a stream would be represented by a
connection and the current transaction if any.

> 
>  - Currently, there's no way to guarantee that certain requests execute
>    sequentially. Streams provide the user with such a way so they can be
>    useful even without transactions. Returning transaction_id can't be
>    used for anything else but interactive transactions.

In other words, with the notion of streams one can submit several
statements in one go. E.g. suppose you need to do N insertions in one
transaction, then with streams you'd do something like this:

 1. Send BEGIN and wait.
 2. Send all INSERTs to the server without waiting for the result.
 3. Wait for the INSERTs to complete successfully.
 4. Send COMMIT and wait.

With transaction_id you'd have to wait after each INSERT:

 1. Send BEGIN and wait for transaction_id.
 2. Send INSERT with transaction_id.
 3. Wait for INSERT to complete.
 4. Go to step 2 until all INSERTs are processed.
 5. Send COMMIT and wait.

I.e. you'd have to incur the overhead associated with the network
latency per each statement.

OTOH do we need such a functionality at all? We already can do batching
in a CALL if we wish. Regarding SQL, INSERT syntax allows to insert
multiple values in one statement AFAIK.

Stream notion would introduce quite a bit of complexity to IProto.
Implementing transaction_id seems to be a much simpler solution.
The only benefit of streams I see is batching, but do we really
need it?