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

Overview

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 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 gets 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"/>
            ... 
        </bean>
    </property>
</bean>
 
CREATE TABLE Person WITH "ATOMICITY=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, there is a possibility 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". The user will have to retry the transaction.

This is how the user will know 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 user will get SQLSTATE:40001 error code.
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");
            tx.commit();
            System.out.println("attempt #" + i + " succeeded");
            break;
        } 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.
                break;
            }
        }
    }
}
 
Class.forName("org.apache.ignite.IgniteJdbcThinDriver");

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

PreparedStatement updateStmt = null;
PreparedStatement selectStmt = null;

try {
    // starting a transaction
    conn.setAutoCommit(false);

    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);
    updateStmt.executeUpdate();

    // committing the transaction
    conn.commit();
} 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();
}

Limitations

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 that can be enabled via JDBC/ODBC connection parameter.

jdbc:ignite:thin://127.0.0.1/?nestedTransactionsMode=COMMIT

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 encountere. 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 some time. 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 for a while.
  • 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 updated 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 will be addressed in the following releases.