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

[Vladimir Davydov]

On Wed, Nov 14, 2018 at 09:45:53PM +0300, Vladislav Shpilevoy wrote:
> 
> > ** 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.
> > 
> > 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?
> > 
> > Should we avoid a fiber_call() when queueing a request? In other words,
> > should streams be implemented inside fiber_pool so that we don't need to
> > execute a call in a fiber in case all it's going to do is just queue a
> > request to be executed by another fiber. This would look cleaner and
> > would probably be more efficient.
> 
> One more question: what to do with pushes? Can I push into a specific
> stream using IPROTO_CHUNK_ID and box.session.push? I think, we should
> allow it. By default box.session.push should push into the stream in
> which it is executed.
> 
> I do not see where you describe a response format, so I guess
> IPROTO_STREAM_ID should be in regular IPROTO_OK/ERROR responses too,
> right?

I'm not quite familiar with box.session.push() implementation, but AFAIU
it doesn't have to do anything with streams. Stream id is simply and
identifier passed along with to a request only. It tells tarantool to
execute the request strictly after all requests with the same stream id
that were submitted earlier have been completed. In other words, we
don't need to pass stream id along with a response or chunk. We already
have syncs to match responses to requests.