[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265759#comment-17265759
]
Aleksey Plekhanov commented on IGNITE-13949:
--------------------------------------------
[~YAMolochkov], do you have a reproducer for this problem? Synchronization can
affect the performance of atomic operations. Perhaps there is nothing wrong
with race here if cache group is used only for atomic or only for tx caches
(but of course there is a problem if mixed tx and atomic caches used in the
same cache group and most probably due to this race, see IGNITE-12854).
Also, if race really affects some operations, perhaps we can solve it using
GridAtomicLong#setIfGreater, without synchronization.
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> ------------------------------------------------------------------
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.9.1
> Reporter: Yaroslav Molochkov
> Assignee: Yaroslav Molochkov
> Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
