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

[Vladislav Shpilevoy]

On 13/11/2018 23:22, Vladimir Davydov wrote:
> 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?
> 

I think, Georgy is right. We should not expose transaction identifiers
to users. It is a internal only thing. What is more, I see that streams
look as a very powerful facility. We can multiplex connections explicitly
on proxies, routers.