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

[Vladislav Shpilevoy]

On 14/11/2018 20:43, Vladimir Davydov wrote:
> 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.
> 

Maybe it is better to do not send IPROTO_STREAM_ID at all when no
streaming?

> > 
> > > 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?

+ 1. Stream is like a virtual connection.