Download Ignite 2.12.0
Apache Ignite

Distributed ACID
Transactions

Classical ACID transactions that let you update distributed data
consistently, durably and with in-memory speed
Distributed ACID transactions

Update multiple records from different tables that span across many cluster nodes

Consistency

Ignite transactional APIs are used by banks to implement payments services that transfer money between accounts in real-time.

Durability

Multi-tier storage persists changes durably to disk. Committed transactions always survive failures, and incomplete transactions are rolled back.

Fault-Tolerance

The transactional engine avoids inconsistencies even if your transaction fails halfway through.

To guarantee data consistency, durability and fault-tolerance,
Ignite implements a two-phase commit protocol

In distributed systems, a transaction usually spans multiple cluster nodes.

To handle possible distributed failures properly and avoid data inconsistencies cluster-wide, a two-phase commit protocol (2PC) is used.

How ACID transactions work

Whenever the records get updated within a transaction, Ignite keeps the transactional state in a local transaction map until the changes are committed.

From here, 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.

If a transaction is mapped to a single node, then Ignite optimizes the transaction execution by switching to the one-phase-commit (1PC) protocol.

Records are updated consistently across
memory and disk tiers

Transactions with Ignite native persistence

In case of any failure you can always recover to a consistent state

When native persistence mode is enabled and Apache Ignite is used as a database that scales beyond available memory capacity, the distributed transactions update data across memory and disk in a consistent way.

All the changes stay durable, because they are written to the write-ahead log (WAL) files. It guarantees data consistency even if the cluster or individual nodes go down in the middle of a transaction.

WAL in details

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.

Transactions with external databases

Your transactions will be updated both in the external database and in Apache Ignite

When Apache Ignite is used as a caching layer for an external database, such as RDBMS, transactions span 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 a 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.

Want to Learn More?

Ignite 3.0 advances its replication and transactional components with the support of the Raft consensus algorithm

Ignite 3.0 and Raft Details