GridGain Developers Hub
GitHub logo GridGain iso
GridGain Software Documentation

Multiversion Concurrency Control


Caches with the TRANSACTIONAL_SNAPSHOT atomicity mode support SQL transactions as well as key-value transactions and enable multiversion concurrency control (MVCC) for both types of transactions.

Multiversion Concurrency Control

Multiversion Concurrency Control (MVCC) is a method of controlling the consistency of data accessed by multiple users concurrently. MVCC implements the snapshot isolation guarantee which ensures that each transaction always sees a consistent snapshot of data.

Each transaction obtains a consistent snapshot of data when it starts and can only view and modify data in this snapshot. When the transaction updates an entry, Ignite verifies that the entry has not been updated by other transactions and creates a new version of the entry. The new version will become visible to other transactions only when and if this transaction commits successfully. If the entry has been updated, the current transaction fails with an exception (see the Concurrent Updates section for the information on how to handle update conflicts).

The snapshots are not physical snapshots but logical snapshots that are generated by the MVCC-coordinator: a cluster node that coordinates transactional activity in the cluster. The coordinator keeps track of all active transactions and is notified when each transaction finishes. All operations with an MVCC-enabled cache request a snapshot of data from the coordinator.

Enabling MVCC

To enable MVCC for a cache, use the TRANSACTIONAL_SNAPSHOT atomicity mode in the cache configuration. If you create a table with the CREATE TABLE command, specify the atomicity mode as a parameter in the WITH part of the command:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="cacheConfiguration">
        <bean class="org.apache.ignite.configuration.CacheConfiguration">

            <property name="name" value="myCache"/>

            <property name="atomicityMode" value="TRANSACTIONAL_SNAPSHOT"/>


Concurrent Updates

If an entry is read and then updated within a single transaction, it is possible that another transaction could be processed in between the two operations and update the entry first. In this case, an exception is thrown when the first transaction attempts to update the entry and the transaction is marked as "rollback only". You will have to retry the transaction.

This is how to tell that an update conflict has occurred:

  • When Java transaction API is used, a CacheException is thrown with the message Cannot serialize transaction due to write conflict (transaction is marked for rollback) and the Transaction.rollbackOnly flag is set to true.

  • When SQL transactions are executed through the JDBC or ODBC driver, the SQLSTATE:40001 error code is returned.

for(int i = 1; i <=5 ; i++) {
    try (Transaction tx = Ignition.ignite().transactions().txStart()) {
        System.out.println("attempt #" + i + ", value: " + cache.get(1));
        try {
            cache.put(1, "new value");
            System.out.println("attempt #" + i + " succeeded");
        } catch (CacheException e) {
            if (!tx.isRollbackOnly()) {
              // Transaction was not marked as "rollback only",
              // so it's not a concurrent update issue.
              // Process the exception here.

// Open JDBC connection.
Connection conn = DriverManager.getConnection("jdbc:ignite:thin://");

PreparedStatement updateStmt = null;
PreparedStatement selectStmt = null;

try {
    // starting a transaction

    selectStmt = conn.prepareStatement("select name from Person where id = 1");
    selectStmt.setInt(1, 1);
    ResultSet rs = selectStmt.executeQuery();

    if (
        System.out.println("name = " + rs.getString("name"));

    updateStmt = conn.prepareStatement("update Person set name = ? where id = ? ");

    updateStmt.setString(1, "New Name");
    updateStmt.setInt(2, 1);

    // committing the transaction
} catch (SQLException e) {
    if ("40001".equals(e.getSQLState())) {
        // retry the transaction
    } else {
        // process the exception
} finally {
    if (updateStmt != null) updateStmt.close();
    if (selectStmt != null) selectStmt.close();
for (int i = 1; i <= 5; i++)
    Transaction tx = ignite.GetTransactions().TxStart();
    std::cout << "attempt #" << i << ", value: " << cache.Get(1) << std::endl;
    try {
        cache.Put(1, "new value");
        std::cout << "attempt #" << i << " succeeded" << std::endl;
    catch (IgniteError e)
        if (!tx.IsRollbackOnly())
            // Transaction was not marked as "rollback only",
            // so it's not a concurrent update issue.
            // Process the exception here.


Cross-Cache Transactions

The TRANSACTIONAL_SNAPSHOT mode is enabled per cache and does not permit caches with different atomicity modes within the same transaction. As a consequence, if you want to cover multiple tables in one SQL transaction, all tables must be created with the TRANSACTIONAL_SNAPSHOT mode.

Nested Transactions

Ignite supports three modes of handling nested SQL transactions. They can be enabled via a JDBC/ODBC connection parameter.


When a nested transaction occurs within another transaction, the nestedTransactionsMode parameter dictates the system behavior:

  • ERROR — When the nested transaction is encountered, an error is thrown and the enclosing transaction is rolled back. This is the default behavior.

  • COMMIT — The enclosing transaction is committed; the nested transaction starts and is committed when its COMMIT statement is encountered. The rest of the statements in the enclosing transaction are executed as implicit transactions.

  • IGNORE — DO NOT USE THIS MODE. The beginning of the nested transaction is ignored, statements within the nested transaction will be executed as part of the enclosing transaction, and all changes will be committed with the commit of the nested transaction. The subsequent statements of the enclosing transaction will be executed as implicit transactions.

Continuous Queries

If you use Continuous Queries with an MVCC-enabled cache, there are several limitations that you should be aware of:

  • When an update event is received, subsequent reads of the updated key may return the old value for a period of time before the MVCC-coordinator learns of the update. This is because the update event is sent from the node where the key is updated, as soon as it is updated. In such a case, the MVCC-coordinator may not be immediately aware of that update, and therefore, subsequent reads may return outdated information during that period of time.

  • There is a limit on the number of keys per node a single transaction can update when continuous queries are used. The updated values are kept in memory, and if there are too many updates, the node might not have enough RAM to keep all the objects. To avoid OutOfMemory errors, each transaction is allowed to update at most 20,000 keys (the default value) on a single node. If this value is exceeded, the transaction will throw an exception and will be rolled back. This number can be changed by specifying the IGNITE_MVCC_TX_SIZE_CACHING_THRESHOLD system property.

Other Limitations

The following features are not supported for the MVCC-enabled caches. These limitations may be addressed in future releases.