...
Data that is stored on the server nodes is represented in a form of key-value pairs. The pairs in their turn are located in specific partitions which belong to individual Ignite caches as it's shown in Picture 2:
Picture 2.
To ensure data consistency and comply with the high-availability principle, server nodes are capable of storing a primary as well as backup copies of data. Basically, there is always a primary copy of a partition with all its key-value pairs in the cluster and might be 0 or more backup copies of the same partition depending on the configuration parameters.
Each cluster node (servers and clients) are aware of all primary and backup copies of every partition. This information is collected and broadcasted to all the nodes from a coordinator (the oldest server node) via internal partition map exchange messages.
However, all the data related requests/operations (get, put, SQL, etc.) go to primary partitions except for some read operations when CacheConfiguration.readFromBackup is enabled. If it's an update operation (put, INSERT, UPDATE) then Ignite ensures that both the primary and backup copies are updated and stay in a consistent state.
...
As the protocol name suggests, a transaction is executed in two phases. The "prepare" phase goes first:
Right after that, the transaction coordinator executes the second phase by sending "commit" message:
Once the backup and primary copies are updated, the transaction coordinator gets acknowledged and assumes that the transaction is finished.
This is how the 2-phase commit works in a nutshell. Below we will see how the protocol tolerates failures, distinguishes pessimistic and optimistic transaction and does many other things.
The transaction coordinator is also known as a near node among Ignite community and committers. The transaction coordinator (near node) initiates a transaction, tracks its state, sends over "prepare" and "commit" message, orchestrates the overall transaction process. Usually, a near node the coordinator is a client node that connects our applications to the cluster. The application issues
...
triggers tx.call(), cache.put()/get(), tx.commit() methods and the client node takes care of the rest as it's shown below:
Picture 5.
In contrast addition to the Near involved in the transaction partitions are called Remote. They keep "their" part of the cache. Physically, every node allocates at part DHT (Distributed hash table) and through afiniti function, any transaction participant may determine its partition and nodes. It should be noted that DHT keeps the buckets to the level of partitioning, and then use B + treecoordinator, the transactional protocol defines remote nodes which are server nodes that keep a part of the data being accessed or updated inside of the transaction. Internally, every server node maintains a distributed hash table (DHT) for partitions it owns. The DHT helps to look up partition owners (primary and backups) efficiently from any cluster node including the transaction coordinator.