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

Concurrency Modes and Isolation Levels

Whenever TRANSACTIONAL atomicity mode is configured, Ignite supports OPTIMISTIC and PESSIMISTIC concurrency modes for transactions. Concurrency mode determines when an entry-level transaction lock should be acquired: at the time of data access or during the prepare phase. Locking prevents concurrent access to an object. For example, when you attempt to update a ToDo list item with pessimistic locking, the server places a lock on the object until you either commit or rollback the transaction so that no other transaction or operation is allowed to update the same entry. Regardless of the concurrency mode used in a transaction, there exists a moment in time when all entries enlisted in the transaction are locked before the commit.

Isolation level defines how concurrent transactions will 'see' and handle operations on the same keys. Ignite supports READ_COMMITTED, REPEATABLE_READ and SERIALIZABLE isolation levels.

All combinations of concurrency modes and isolation levels can be used simultaneously. Below is the description of Ignite behavior and the guarantees provided by each concurrency-isolation combination.

Pessimistic Transactions

In PESSIMISTIC transactions, locks are acquired during the first read or write access (depending on the isolation level) and held by the transaction until it is committed or rolled back. In this mode locks are acquired on primary nodes first and then promoted to backup nodes during the prepare stage. The following isolation levels can be configured with PESSIMISTIC concurrency mode:

  • READ_COMMITTED - Data is read without a lock and is never cached in the transaction itself. The data may be read from a backup node if this is allowed in the cache configuration. In this isolation you can have the so-called Non-Repeatable Reads because a concurrent transaction can change the data when you are reading the data twice in your transaction. The lock is only acquired at the time of first write access (this includes EntryProcessor invocation). This means that an entry that has been read during the transaction may have a different value by the time the transaction is committed. No exception will be thrown in this case.

  • REPEATABLE_READ - Entry lock is acquired and data is fetched from the primary node on the first read or write access and stored in the local transactional map. All consecutive access to the same data is local and will return the last read or updated transaction value. This means no other concurrent transactions can make changes to the locked data, and you are getting Repeatable Reads for your transaction.

  • SERIALIZABLE - In PESSIMISTIC mode, this isolation level works the same way as REPEATABLE_READ.

Note that in PESSIMISTIC mode, the order of locking is important. Moreover, Ignite will acquire locks sequentially and exactly in the specified order.

Performance Considerations

Imagine that you have 3 nodes in your topology (A, B, C) and in your transaction you are doing a putAll for keys [1, 2, 3, 4, 5, 6]. Suppose that these keys are mapped to nodes in the following fashion: {A: 1, 4}, {B: 2, 5}, {C: 3, 6}. Since Ignite cannot re-arrange the lock acquisition order in PESSIMISTIC mode, it will have to make 6 sequential network round-trips: [A, B, C, A, B, C]. In a case when the key locking order is not important for the semantics of a transaction, it is advisable to group keys by partition and lock keys within the same partition together. This may significantly reduce the number of network messages in a large transaction. In this example, if keys were ordered for a putAll in the following way: [1, 4, 2, 5, 3, 6], then only 3 sequential round-trips would be required.

Topology Change Restrictions

Note that if at least one PESSIMISTIC transaction lock is acquired, it will be impossible to change the cache topology until the transaction is committed or rolled back. Therefore, you should avoid holding transaction locks for long periods of time.

Optimistic Transactions

In OPTIMISTIC transactions, entry locks are acquired on primary nodes during the first phase of 2PC, at the prepare step, and then promoted to backup nodes and released once the transaction is committed. The locks are never acquired if you roll back the transaction and no commit attempt was made. The following isolation levels can be configured with OPTIMISTIC concurrency mode:

  • READ_COMMITTED - Changes that should be applied to the cache are collected on the originating node and applied upon the transaction commit. Transaction data is read without a lock and is never cached in the transaction. The data may be read from a backup node if this is allowed in the cache configuration. In this isolation you can have so-called Non-Repeatable Reads because a concurrent transaction can change the data when you are reading the data twice in your transaction. This mode combination does not check if the entry value has been modified since the first read or write access and never raises an optimistic exception.

  • REPEATABLE_READ - Transactions at this isolation level work similar to OPTIMISTIC READ_COMMITTED transactions with only one difference: read values are cached on the originating node and all subsequent reads are guaranteed to be local. This mode combination does not check if the entry value has been modified since the first read or write access and never raises an optimistic exception.

  • SERIALIZABLE - Stores an entry version upon first read access. Ignite will fail a transaction at the commit stage if the Ignite engine detects that at least one of the entries used as part of the initiated transaction has been modified. This is achieved by internally checking the version of an entry remembered in a transaction to the one actually in the grid at the time of commit. In short, this means that if Ignite detects that there is a conflict at the commit stage of a transaction, it will fail the transaction, throwing TransactionOptimisticException and rolling back any changes made. Make sure you handle this exception and retry the transaction.

// Re-try transaction finite amount of time.
int retryCount = 10;
int retries = 0;

// Start transaction in optimistic mode with serializable isolation level.
while (retries < retryCount) {
    retries++;
    try (Transaction tx =  
        ignite.transactions().txStart(TransactionConcurrency.OPTIMISTIC,
                                      TransactionIsolation.SERIALIZABLE)) {
        // Modify cache entries as part of this transaction.
        ....
        
        // commit transaction.  
        tx.commit();

        // Transaction succeeded. Leave the while loop.
        break;
    }
    catch (TransactionOptimisticException e) {
        // Transaction has failed. Retry.
    }
}

Another important point to note here is that a transaction will still fail even if an entry was read without being modified (cache.put(...)), since the value of the entry could be important to the logic within the initiated transaction.

Note that the key order is important for READ_COMMITTED and REPEATABLE_READ transactions since the locks are still acquired sequentially in these modes.

Retrying Optimistic Serializable Transactions

It is always a good idea to retry a failed optimistic serializable transaction because the data the transaction was trying to update might have been changed concurrently. Therefore, the TransactionOptimisticException should be handled with retry logic. It is reasonable to constrain the retry count with a limit.

Read Consistency

In order to achieve full read consistency in PESSIMISTIC mode, read-locks need to be acquired. This means that full consistency between reads in PESSIMISTIC mode can be achieved only with PESSIMISTIC REPEATABLE_READ (or SERIALIZABLE) transactions.

When using OPTIMISTIC transactions, full read consistency can be achieved by disallowing potential conflicts between reads. This behavior is provided by OPTIMISTIC SERIALIZABLE mode. Note, however, that until the commit happens you can still read a partial transaction state, so the transaction logic must protect against it. Only during the commit phase, in case of any conflict, a TransactionOptimisticException will be thrown allowing you to retry the transaction.

If you are not using PESSIMISTIC REPEATABLE_READ or SERIALIZABLE transactions or OPTIMISTIC SERIALIZABLE transactions, then it is possible to see a partial transaction state. This means that if one transaction updates objects A and B, then another transaction may see the new value for A and the old value for B.

Concurrency Modes and Isolation Levels


Suggested Edits are limited on API Reference Pages

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