Apache Ignite Documentation

GridGain Developer Hub - Apache Ignitetm

Welcome to the Apache Ignite developer hub run by GridGain. Here you'll find comprehensive guides and documentation to help you start working with Apache Ignite as quickly as possible, as well as support if you get stuck.


GridGain also provides Community Edition which is a distribution of Apache Ignite made available by GridGain. It is the fastest and easiest way to get started with Apache Ignite. The Community Edition is generally more stable than the Apache Ignite release available from the Apache Ignite website and may contain extra bug fixes and features that have not made it yet into the release on the Apache website.


Let's jump right in!


Documentation     Ask a Question     Download


Javadoc     Scaladoc     Examples

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.


Beta version of Transactional SQL and MVCC

In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to allow users to experiment and share feedback. This version of Transactional SQL and MVCC should not be considered for production.

Multiversion Concurrency Control

Multiversion Concurrency Control (MVCC) is a method of controlling 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 hasn't 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"/>


The TRANSACTIONAL_SNAPSHOT mode only supports the default concurrency mode (PESSIMISTIC) and default isolation level (REPEATABLE_READ). See Concurrency modes and isolation levels for details.

Concurrent Updates

If an entry is read and then updated within a single transaction, it is possible that another transaction may cut in between the two operations and update that 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 (rs.next())
        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();


Cross-Cache Transactions

The TRANSACTIONAL_SNAPSHOT mode is enabled per cache and does not permit caches with different atomicity modes within one 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 system behavior depends on the nestedTransactionsMode parameter:

  • 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 commited 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 and 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. This limitations may be addressed in later releases.

Updated about a year ago

Multiversion Concurrency Control

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.