blob: 409ac6ca836d588d524270cccbc5c34e10d95a90 [file] [log] [blame]
<!--
▄▄▄ ██▓███ ▄▄▄ ▄████▄ ██░ ██ ▓█████ ██▓ ▄████ ███▄ █ ██▓▄▄▄█████▓▓█████
▒████▄ ▓██░ ██▒▒████▄ ▒██▀ ▀█ ▓██░ ██▒▓█ ▀ ▓██▒ ██▒ ▀█▒ ██ ▀█ █ ▓██▒▓ ██▒ ▓▒▓█ ▀
▒██ ▀█▄ ▓██░ ██▓▒▒██ ▀█▄ ▒▓█ ▄ ▒██▀▀██░▒███ ▒██▒▒██░▄▄▄░▓██ ▀█ ██▒▒██▒▒ ▓██░ ▒░▒███
░██▄▄▄▄██ ▒██▄█▓▒ ▒░██▄▄▄▄██ ▒▓▓▄ ▄██▒░▓█ ░██ ▒▓█ ▄ ░██░░▓█ ██▓▓██▒ ▐▌██▒░██░░ ▓██▓ ░ ▒▓█ ▄
▓█ ▓██▒▒██▒ ░ ░ ▓█ ▓██▒▒ ▓███▀ ░░▓█▒░██▓░▒████▒ ░██░░▒▓███▀▒▒██░ ▓██░░██░ ▒██▒ ░ ░▒████▒
▒▒ ▓▒█░▒▓▒░ ░ ░ ▒▒ ▓▒█░░ ░▒ ▒ ░ ▒ ░░▒░▒░░ ▒░ ░ ░▓ ░▒ ▒ ░ ▒░ ▒ ▒ ░▓ ▒ ░░ ░░ ▒░ ░
▒ ▒▒ ░░▒ ░ ▒ ▒▒ ░ ░ ▒ ▒ ░▒░ ░ ░ ░ ░ ▒ ░ ░ ░ ░ ░░ ░ ▒░ ▒ ░ ░ ░ ░ ░
░ ▒ ░░ ░ ▒ ░ ░ ░░ ░ ░ ▒ ░░ ░ ░ ░ ░ ░ ▒ ░ ░ ░
░ ░ ░ ░░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░
-->
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<link rel="canonical" href="https://ignite.apache.org/features/acid-transactions.html" />
<!--#include virtual="/includes/scriptshead.html" -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
<title>ACID Transactions - Apache Ignite</title>
<meta name="description"
content="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."/>
<!--#include virtual="/includes/styles.html" -->
</head>
<body>
<!--#include virtual="/includes/header.html" -->
<article>
<header>
<div class="container">
<h1><strong>ACID Transactions</strong> with Apache Ignite</h1>
</div>
</header>
<div class="container">
<p>
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.
</p>
<img class="img-responsive diagram-right" src="/images/svg-diagrams/acid_transactions.svg" alt="Apache Ignite ACID Transactions" />
<p>
Distributed transactions in Apache Ignite can span multiple cluster nodes, caches/tables, and
partitions. Both pessimistic and optimistic locking is available for applications.
</p>
<h2>Two-Phase-Commit Protocol</h2>
<p>
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).
</p>
<p>
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.
</p>
<h2>Consistency and Ignite Persistence</h2>
<p>
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.
</p>
<h2>Consistency and 3rd Party Persistence</h2>
<p>
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.
</p>
<div class="jumbotron jumbotron-fluid">
<div class="container">
<div class="title display-6">Learn More</div>
<hr class="my-4">
<div class="row">
<div class="col-sm-6">
<ul>
<li><a href="/docs/latest/key-value-api/transactions">Ignite Transactions <i class="fas fa-angle-double-right"></i></a></li>
</ul>
</div>
<div class="col-sm-6">
<ul>
<li><a href="/docs/latest/key-value-api/transactions#deadlock-free-transactions">Deadlock-free transactions and detection <i class="fas fa-angle-double-right"></i></a></li>
</ul>
</div>
</div>
</div>
</div>
</div>
</article>
<!--#include virtual="/includes/footer.html" -->
<!--#include virtual="/includes/scripts.html" -->
</body>
</html>