The transaction model of Tarantool corresponds to the properties ACID (atomicity, consistency, isolation, durability).
Tarantool has two modes of transaction behavior:
- Default – suitable for fast monopolistic atomic transactions
- MVCC – designed for long-running concurrent transactions
Each transaction in Tarantool is executed in a single fiber on a single thread, sees a consistent database state and commits all changes atomically.
All transaction changes are written to the WAL (Write Ahead Log) in a single batch in a specific order at the time of the commit. If needed, transaction changes can also be rolled back – completely or to a specified savepoint.
Therefore, every transaction in Tarantool has the highest transaction isolation level – serializable.
By default, the isolation level of Tarantool is serializable.
The exception is a failure during writing to the WAL, which can occur, for example, when the disk space is over.
In this case, the isolation level of the concurrent read transaction would be
The MVСС mode provides several options that enable you to tune the visibility behavior during transaction execution.
read-committed isolation level makes visible all transactions that started commit (box.commit() was called).
Write transactions with reads
Manual usage of
read-committedfor write transactions with reads is completely safe, as this transaction will eventually result in a commit. If a previous transactions fails, this transaction will inevitably fail as well due to the serializable isolation level.
Manual usage of
read-committedfor read transactions may be unsafe, as it may lead to phantom reads.
read-confirmed isolation level makes visible all transactions that finished
the commit (box.commit() was returned).
This means that new data is already on disk or even on other replicas.
The use of
read-confirmedis safe for read transactions given that data is on disk (for asynchronous replication) or even in other replicas (for synchronous replication).
To achieve serializable, any write transaction should read all data that has already been committed. Otherwise, it may conflict when it reaches its commit.
Linearizability of read operations implies that if a response for a write request arrived earlier than a read request was made, this read request should return the results of the write request.
When called with
linearizable, box.begin() yields until the instance receives enough data from remote peers to be sure that the transaction is linearizable.
Linearizable transactions may only perform requests to the following memtx space types:
A linearizable transaction can fail with an error in the following cases:
- If the node can’t contact enough remote peers to determine which data is committed.
- If the data isn’t received during the
To start a linearizable transaction, the node should be the replication source for at least
N - Q + 1 remote replicas.
N is the count of registered nodes in the cluster and
Q is replication_synchro_quorum.
So, for example, you can’t perform a linearizable transaction on anonymous replicas because they can’t be the source of replication for other nodes.
To minimize the possibility of conflicts, MVCC uses what is called
- for write transactions, MVCC chooses read-committed
- for read transactions, MVCC chooses read-confirmed
This inevitably leads to the serializable isolation level. Since there is no option for MVCC to analyze the whole transaction to make a decision, it makes the choice on the first operation.
If the serializable isolation level becomes unreachable, the transaction is marked as “conflicted” and rolled back.