]
RH Bugzilla Integration commented on ISPN-3422:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug
In non-tx caches, write operations may not be atomic during
rebalance
---------------------------------------------------------------------
Key: ISPN-3422
URL:
https://issues.jboss.org/browse/ISPN-3422
Project: Infinispan
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Labels: 620, nbst
Fix For: 6.1.0.Final
If the cache topology changes while a write command is running and before it has actually
committed the entry to the data container, we retry the command (see ISPN-3366 and
ISPN-3357). But before we detect the topology change, one or more of the backup owners may
have already applied the modification.
Retrying the command re-acquires the key lock on the primary owner (even if the primary
owner didn't change). That means another command could have modified the same key in
the meantime, but the retried command is going to ignore any changes and is going to
return the value before the first attempt. Obviously, the command is not retried if the
first attempt is not successful, but scenarios like this are possible:
{code}
thread 1: putIfAbsent(k, v1) -> null
thread 2: putIfAbsent(k, v2) -> null
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: