Details
-
Sub-task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
-
Docs Required, Release Notes Required
Description
The suggestion is to simplify and separate the counters API. `PartitionUpdateCounter` should be splited into transactional and amotic ones. Unwrap where neded. Atomic caches have no LWM/HWM and related methods. The method namings should correspond to the javadocs like lwm()/hwm().
Also, looks like MVCC couneters might have own implementation. We should consider transaction model when working and storing the counters.
Suggestions to improve:
1. Use some separated counter interfaces for atomic and transactional caches.
2. 'get()' should be renamed to 'lwm()'
3. 'reserved()' -> 'hwm()' which is probably highestAppliedCounter().
'reserved()' is uncertain. It is only for primary node. Do we need it in a interface? Should be removed.
It is used only in CacheContinuousQueryHandler, see [1].
4. Many setters 'update()' / 'update(long start, long delta)' / 'next()' / 'next(long delta)' / 'reset()' / 'resetInitial()' look over-engineered. Should be unified.
5. 'next()' and 'next(long delta)' have wierd implementations in PartitionUpdateCounterTrackingImpl. 'next(long delta)' doesn't update the reserved counter. Shoulbe be revised.
6. Reduce synchronized methods in counters like 'PartitionUpdateCounterTrackingImpl#reserve(long delta)'
7. Use same method names in related GridDhtLocalPartition. Not 'reserved()/reservedCounter()'
Related design doc: https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
Attachments
Issue Links
- blocks
-
IGNITE-22344 Tx counters refactoring
- Open
- is related to
-
IGNITE-18281 Return highestAppliedCounter as HWM in reserved() method
- In Progress
- relates to
-
IGNITE-17793 Historical rebalance must use HWM instead of LWM to seek the proper checkpoint to avoid the data loss
- Resolved