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

[Konstantin Osipov]

* Vladislav Shpilevoy <v.shpilevoy at tarantool.org> [18/11/15 01:41]:
> > > > 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?
> > 
> > The number of incoming connections is limited implicitly by
> > ulimit. A connection doesn't take database resources, it only
> > consumers memory buffers and file descriptors. An open transaction
> > potentially holds a lot more resources. E.g. a typical graph-based
> > deadlock detector has complexity O(N^2) on the number of
> > transactions.
> 
> Streams have nothing to do with deadlock resolvers or transactions.
> Even without streams and even now I can create thousands of active
> transactions. Streams are at a lower level that transactions. You
> for unknown reason think that stream == transaction, but it is false.

You forget the reason we're adding streams. We can't use today's
connections since they are mostly stateless. We need to add a
state to the connection - an open transaction. And to be able to
multiplex multiple states over the same connection, we're adding
streams. 

If you try to look where this is heading, it's a full support of
SQL features related to current session.

The spec already says very little about impact on changes to the
current session made in one stream to another stream - they can be
dramatic. What if, for example, I change sql_default_engine in one
stream, will it impact another? What about the current user? 

In SQL, there are the following attributes of the session:

- current user
- transaction
- transaction isolation level
- client character set 
- state of the diagnostics area
- temporary table data

Are these going to be shared between streams? In other words, are
you going to only make "the current transaction" a server side
context of the stream, and share everything else? I think then you
will stumble over the first subsequent requirement of ANSI we will
eventually get to do. Besides, proxying won't work as intended.


-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov