[
https://issues.apache.org/jira/browse/IGNITE-18343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-18343:
--------------------------------------
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. Use same method names in related GridDhtLocalPartition. Not
'reserved()/reservedCounter()'
Related design doc:
https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
[1] https://issues.apache.org/jira/browse/IGNITE-18281
was:
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.
Related design doc:
https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
[1] https://issues.apache.org/jira/browse/IGNITE-18281
> Refactor partition counters API.
> --------------------------------
>
> Key: IGNITE-18343
> URL: https://issues.apache.org/jira/browse/IGNITE-18343
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladimir Steshin
> Priority: Major
>
> 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. Use same method names in related GridDhtLocalPartition. Not
> 'reserved()/reservedCounter()'
> Related design doc:
> https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency
> [1] https://issues.apache.org/jira/browse/IGNITE-18281
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
