Create your transactional application
with Apache Ignite
Ignite transactional APIs are used by banks to implement payments services that transfer money between accounts in real-time.
Multi-tier storage persists changes durably to disk. Committed transactions always survive failures, and incomplete transactions are rolled back.
The transactional engine avoids inconsistencies even if your transaction fails halfway through.
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.
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.
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.
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.
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.