[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 ] Anton Vinogradov updated IGNITE-18343: -- Parent: IGNITE-17845 Issue Type: Sub-task (was: Improvement) > Refactor partition counters API. > > > Key: IGNITE-18343 > URL: https://issues.apache.org/jira/browse/IGNITE-18343 > Project: Ignite > Issue Type: Sub-task >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. 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 > [1] https://issues.apache.org/jira/browse/IGNITE-18281 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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. 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 [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. 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 > 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. 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 > [1] https://issues.apache.org/jira/browse/IGNITE-18281
[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. 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)
[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)
