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

[Vladimir Davydov]

On Wed, Nov 14, 2018 at 06:25:30PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev at gmail.com> [18/11/13 20:51]:
> >  6. If IPROTO_STREAM_ID is unset (0), everything works as before, i.e.
> >     no transaction preservation or request serialization will occur.
> 
> I think this is a bit confusing. Logically they all must belong to
> stream id 0, but suddenly they all belong to (internally) distinct
> streams. What if I do begin on the client without an assigned
> stream id? Will I have a stream created automatically? What if I
> do a commit for a non-existent stream id? 

IMO stream id 0 means no streaming and hence no interactive
transactions.

> 
> > The net.box API will look like this:
> > 
> >   c = net_box.connect(...)
> >   s = c:make_stream(stream_id)
> >   s:call(...)
> > 
> > A net.box stream instance will be a wrapper around the connection it was
> > created for. It will have all the same methods as the connection itself,
> > but all requests sent on its behalf will have the stream id attached.
> 
> This is nice.
> 
> > ** Questions **
> > 
> > Should we limit the number of streams somehow? I don't think so, at
> > least not right now, because streams are completely user controlled,
> > like iproto connections.
> > 
> 
> Definitely, it should be a global limit, a new box.cfg setting (as
> much as I hate settings there is no waywe can do away without it
> here afaiu).

But why? We don't limit the number of incoming connections. Why should
we bother with limiting streams?

> 
> > How to close a stream so that the corresponding stream object is
> > destroyed on the server? Do we need to bother at all? May be dropping
> > all streams along with a connection would be enough?
> 
> No, it's definitely not enough. We need to think about denial of
> service attacks and hogging all server memory by creating too many
> streams. This is especially important since automatic streams
> (those that are created if stream id is not set) will also take
> resources. Perhaps wee should forbid interactive transactions in
> stream id 0, this would at least be safe.
> 
> Please also state explicitly what happens with open transactions
> in a stream when a connection is closed. And yes, I presume ppl

When a connection is closed, all corresponding streams are destroyed and
all transactions are closed.

> will ask for ways to control the stream so we better think right
> now what these ways could be (even if we decide to not implement
> them at once).

We could destroy a stream in case there's no pending requests for this
stream id and no open transaction. That is a stream exists on the server
side long as there's an uncommitted transaction in it. We could also
rollback the transaction used by a stream and destroy the stream by
timeout, I guess.