| extend ../_components/base.pug |
| |
| block pagetitle |
| | ACID transactions |
| |
| block css |
| link(rel="stylesheet", href="../css/native-persistence.css?ver=" + config.version) |
| link(rel="stylesheet", href="../css/acid-transactions.css?ver=" + config.version) |
| |
| |
| |
| block main |
| - global.pageHref = "features" |
| - config.hdrClassName = "hdr__blue" |
| include ../_components/header.pug |
| |
| |
| section.innerhero |
| .container.innerhero__cont |
| .innerhero__main |
| .innerhero__pre.pb-5 Apache Ignite |
| h1.h1.innerhero__h1 Distributed ACID <br>Transactions |
| //- .pt-2.h3 with Apache Ignite |
| .innerhero__descr.pt-4.h5. |
| Classical ACID transactions that let you update distributed data <br>consistently, durably and with in-memory speed |
| .innerhero__action |
| a.button.innerhero__button(href="https://ignite.apache.org/docs/latest/index") Start Coding |
| img.innerhero__pic.innerhero__pic--acid(src="/img/features/acid/hero.svg", alt="Distributed ACID transactions") |
| // /.innerhero |
| |
| |
| |
| |
| |
| |
| section.acid1.container |
| h2.acid1__h2.h4 Update multiple records from different tables that span across many cluster nodes |
| .acid1__wrap.flexi |
| .acid1__item |
| .acid1__title.fz20 Consistency |
| .acid1__text.pt-3 |
| p Ignite transactional APIs are used by banks to implement payments services that transfer money between accounts in real-time. |
| .acid1__item |
| .acid1__title.fz20 Durability |
| .acid1__text.pt-3 |
| p Multi-tier storage persists changes durably to disk. Committed transactions always survive failures, incomplete transactions are rolled back. |
| .acid1__item |
| .acid1__title.fz20 Fault-Tolerance |
| .acid1__text.pt-3 |
| p The transactional engine avoids inconsistencies even if your transaction is failed in the middle of a commit. |
| // /.acid1 |
| |
| |
| |
| |
| section.acid2.container |
| h2.acid2__h2 To guarantee data consistency, durability and fault-tolerance<br> <strong>Ignite implements the two-phase commit protocol</strong> |
| .acid2__wrap.flexi.pt-5 |
| .acid2__main |
| p In distributed systems, a transaction usually spans across multiple cluster nodes. |
| p To handle possible distributed failures properly and avoid data inconsistencies cluster-wide, a two-phase commit protocol (2PC) is used. |
| h3.acid2__subtitle.h5.pb-2 How ACID transactions work |
| p Whenever the records get updated within a transaction, Ignite keeps the transactional state in a local transaction map until the changes are committed. |
| p 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. |
| p If a transaction is mapped to a single node, then, Ignite optimizes the transaction execution by switching to the one-phase-commit (1PC) protocol. |
| aside.acid2__right |
| img(src="/img/features/acid/acid-func.svg", alt="").acid2__funcimg |
| // /.acid2 |
| |
| |
| |
| section.acid3.container.pt-5 |
| h2.h4.acid3__title Records are updated consistently across <br>memory and disk tiers |
| .acid3__wrap.pt-5.flexi |
| .acid3__col |
| h3.h5.pb-2 Transactions with Ignite native persistence |
| p.fz20.acid3__collead In case of any failure you can always recover to a consistent state |
| .acid3__small.pt-4 |
| p 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. |
| p 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. |
| a.acid3__detlink(href="#", data-hideopen="acidbox") WAL in details |
| .acid3__detwrap(data-hidebox="acidbox") |
| .acid3__detmore |
| button.acid3__close(data-hideopen="acidbox") |
| img(src="/img/features/acid/icon-cross.svg", alt="") |
| p 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. |
| p.pt-1 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. |
| .acid3__col |
| h3.h5.pb-2 Transactions with external databases |
| p.fz20.acid3__collead Your transactions will be updated both i external database and Apache Ignite |
| .acid3__small.pt-4 |
| p 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. |
| p 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. |
| p 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. |
| |
| |
| section.native-bottom.container |
| .native-bottom__grid |
| article.nativebotblock |
| h3.h4.nativebotblock__title |
| img(src="/img/features/native-rocket.svg", alt="").nativebotblock__icon |
| span Ready to Start? |
| p.nativebotblock__text Create your transactional application <br>with Apache Ignite |
| a.nativebotblock__link.arrowlink(href="https://ignite.apache.org/docs/latest/key-value-api/transactions", target="_blank") Performing ACID Transactions |
| article.nativebotblock.nativebotblock--learn |
| h3.h4.nativebotblock__title |
| img(src="/img/features/native-docs.svg", alt="").nativebotblock__icon |
| span Want to Learn More? |
| p.nativebotblock__text Ignite 3.0 advances its replication and transactional components with the support of the <strong>Raft consensus algorithm</strong> |
| a.nativebotblock__link.arrowlink(href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-61%3A+Common+Replication+Infrastructure", target="_blank") Ignite 3.0 and Raft Details |
