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

[Vladislav Shpilevoy]

On 15/11/2018 11:19, Vladimir Davydov wrote:
> 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.
> 

Yes, you are right. Sync is enough.