You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Steshin (Jira)" <ji...@apache.org> on 2022/12/07 06:41:00 UTC
[jira] [Updated] (IGNITE-18343) Refactor partition counters API.
[ 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.
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. Unwrap where neded. Atomic caches have no LWM/HWM and related methods. The methods 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 at least 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
Summary: Refactor partition counters API. (was: Refactor partition counters APIs.)
> 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.
> 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)