...
F(5) = s2, s3, s4, s1
Node s4 owns will own all 6 partitions and will load them during rebalancing.
...
/** High watermark. */
protected final AtomicLong reserveCntr = new AtomicLong();
High watermark or reservation counter is incremented for each pending update, which even not guaranteed to succeed. Reservation counter is assigned during tx prepare phase.
For example, LWM=5 and HWM=9 means four updates numbered 6,7,8,9 are on the fly.
/** Updates applied out of order. */
private SortedSet<Range> seq = new TreeSet<>();
...
A range represents a sequence of updates, for example (5, 3) means three updates with number 6, 7, 8.
Out of order updates range is held in the sequence only if an update with lower range is missing. For example, LWM=5, HWM=9, seq=(6,2) means updates 7, 8 were applied out of order and updates 6, 9 are still not applied.
Where is an important invariant which can be concluded from statements above:
...
We will use an example to understand illustrate the flow.
Suppose we have 3 server nodes and 1 client node in topology.
Two threads start two pessimistic (TODO javadoc ref) transactions concurrently updating keys belonging to the single partition p. Backups count is equal to 2 so total number of onwers owners is 3.
Tx1 enlists and updates keys k1, k2, k3, Tx2 enlists and updates keys k4, k5.
...
F(k1) = F(k2) = F(k3) = F(k4) = F(k5) = s1, s2, s3TODO format as code
Ignite client = startClient();
IgniteCache<Integer, Integer> cache = client.cache(name);
...
The figure below shows the flow with the case of backup reordering, where tx with higher update counters is applied before tx with lower update counters on backup.
TODO fig
The first step (near map) on the near(originating) node is to calculate near map of this transaction - for each partition p a set of involved primary nodes using the affinity function F(p) . In our case same and only one primary node for both transactions.
...