ACID Transactions

Apache Ignite is a strongly consistent platform that fully supports distributed ACID transactions. The consistency guarantees are met for both memory and disk tiers.

Transactions in Apache Ignite can span multiple cluster nodes, caches (aka. tables) and partitions. Both pessimistic and optimistic locking are available for applications. The optimistic mode also supports deadlock-free transactions that help avoid distributed deadlocks in user code.

Two-Phase-Commit Protocol

In a distributed system, a transaction may span multiple cluster nodes. Obviously, this poses some challenges when we want to ensure that the data is consistent across all the participating nodes. For example, in the event of a cluster node failure, the transaction may not have fully committed on the lost node. A widely-used approach to ensuring data consistency in this type of scenario is the two-phase commit protocol (2PC).

Ignite comes with one the fastest implementations of 2PC protocol. Moreover, often when transactions span only one node or one partition, Ignite will utilize a much faster one-phase-commit (1PC) protocol. Whenever the data is updated within a transaction, Ignite will keep the transactional state in a local transaction map until the changes are committed, at which point the data is transferred to the participating remote nodes. Only the nodes that hold the primary or backup copies of the data will participate in the transaction.

Consistency and Ignite Persistence

If Ignite native persistence is used then all the updates are written to the write-ahead log (WAL) file that guarantees data consistency, even if the cluster or individual nodes go down in the middle of a transaction.

The purpose of the WAL is to propagate updates to the disk in the append-only mode, which is the fastest way to persist data to disk. WAL provides a recovery mechanism for failure scenarios when a single node or the whole cluster go down. A cluster can always be recovered to the latest successfully committed transaction.

Consistency and 3rd Party Persistence

In scenarios when Ignite is used as a caching layer on top of 3rd party databases, such as RDBMS, Ignite transactions will span both, the cached data and the external database. For instance, when an RDBMS is used as a persistence layer, Ignite will write the transactional changes to the database before it sends the commit message to participating cluster nodes. This way, if a transaction fails at the database level, Ignite can still send the rollback message to every node involved, keeping the data consistent between the in-memory cache and the external database.

Code Examples
                            try (Transaction tx = transactions.txStart()) {
                                Integer hello = cache.get("Hello");

                                if (hello == 1)
                                    cache.put("Hello", 11);

                                    cache.put("World", 22);

                            using (ITransaction tx = transactions.TxStart())
                                var hello = cache.Get(1);

                                if (hello != "Hello")
                                    cache.Put(1, "Hello");

                                    cache.Put(2, "World");

                        Transaction tx = transactions.TxStart();

                        int hello = cache.Get("Hello");

                        if (hello == 1)
                            cache.Put("Hello", 11);

                        cache.Put("World", 22);

More on Ignite Transactions
Feature Description
ACID Transactions

Ignite provides fully ACID compliant distributed transactions that ensure guaranteed consistency.


Ignite utilizes a Two-Phase-Commit (2PC) protocol for its transactions and optimizes to one-phase-commit whenever possible:

Write-Ahead Log

Ignite persistence maintains the WAL that propagates updates to disk in the fastest way possible and provides a recovery mechanism for scenarios where a single node or the whole cluster goes down:

Deadlock-Free Transactions

Ignite supports deadlock-free, optimistic transactions, which do not acquire any locks.

Deadlocks Detection

Debugging and troubleshooting distributed deadlocks in Ignite:

Transactional Entry Processor

Ignite transactional entry processor allows executing collocated user logic on the server side within a transaction:

Cross-Partition Transactions

In Ignite, transactions can be performed on all partitions of a cache across the whole cluster:


Ignite allows developers to define explicit locks enforcing mutual exclusion on cached objects:


Ignite can be configured with a Java Transaction API (JTA) transaction manager lookup class.