Apache Ignite® can operate in a strongly consistent mode with full support for distributed ACID transactions. The consistency guarantees are met for both memory and disk tiers.
Distributed transactions in Apache Ignite can span multiple cluster nodes, caches/tables, and partitions. Both pessimistic and optimistic locking is available for applications.
In distributed systems, a transaction usually spans across multiple cluster nodes. This requires transactional engines to handle possible distributed failures properly to avoid data inconsistencies cluster-wide. One of the widely-used approaches to ensure data consistency in such a scenario is the two-phase commit protocol (2PC).
Ignite transactional engine implements the 2PC protocol. Whenever the records get 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 primary or backup copies of the data participate in the transaction. Moreover, if a transaction is mapped to a single node, then Ignite optimizes the transaction execution by switching to the one-phase-commit (1PC) protocol.
Consistency and Ignite Persistence
If Ignite native persistence is used, then all the updates are written to the write-ahead log (WAL), which 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. The WAL provides a recovery mechanism for failure scenarios when a single node or the whole cluster goes down. A cluster can always be recovered to the latest successfully committed transaction.
Consistency and 3rd Party Persistence
In scenarios where Ignite is used as a caching layer for an external database, such as RDBMS, Ignite transactions span both the cached data in Ignite as well as the data persisted in a database supporting transactional APIs. For instance, if a relational database is configured as the disk tier, Ignite writes the transactional changes to the database before sending a commit message to participating cluster nodes. This way, if a transaction fails at the database level, Ignite can still send the rollback message to the cluster nodes, keeping the data consistent across memory and disk tiers.