Streams and interactive transactions | Tarantool
Check out the new release policy
Streams and interactive transactions

Streams and interactive transactions

Since v. 2.10.0-beta1, iproto implements streams and interactive transactions.

A stream supports multiplexing several transactions over one connection. All requests in the stream are executed strictly sequentially, which allows the implementation of interactive transactions.

Unlike a thread associated with multitasking and execution within a program, a stream transfers data via the protocol between a client and a server.

Interactive transaction
An interactive transaction is a transaction that does not need to be sent in a single request. The begin, commit, and other TX statements can be sent and executed in different requests.

The primary purpose of streams is to execute transactions via iproto. Every stream has its own identifier, which is unique within the connection. All requests with the same non-zero stream ID belong to the same stream. All requests in the stream are processed synchronously. The next request will not start executing until the previous one is completed. If a request’s stream ID is 0, it does not belong to any stream and is processed in the old way.

In, a stream is an object above the connection that has the same methods but allows executing requests sequentially. The ID is generated on the client side automatically. If a user writes their own connector and wants to use streams, they must transmit the stream_id over the iproto protocol.

Interactive transactions over streams only work if the box.cfg{} option memtx_use_mvcc_engine is enabled on the server: memtx_use_mvcc_engine = true.

As each stream can start a transaction, several transactions can be multiplexed over one connection. There are multiple ways to begin, commit, and roll back a transaction. One can do that using the appropriate stream methods—call, eval, or execute—with the SQL transaction syntax. Users can mix these methods. For example, one might start a transaction using stream:begin() and commit it with stream:call('box.commit') or stream:execute('COMMIT'). All the requests between stream:begin() and stream:commit() are executed within the same transaction. If any request fails during the transaction, it will not affect the other requests in the transaction. If a disconnect occurs while there is an active transaction in the stream, that transaction will be rolled back if it hasn’t been committed before the connection failure.


local conn = net_box.connect(remote_server_addr)
local conn_space =
local stream = conn:new_stream()
local stream_space =

-- Begin transaction over an iproto stream:

-- Empty select, the transaction was not committed.
-- You can't see it from the requests that do not belong to the
-- transaction.

-- Select returns the previously inserted tuple,
-- because this select belongs to the transaction:

-- Commit transaction:

-- Now this select also returns the tuple, because the transaction has been committed: