[
https://issues.jboss.org/browse/ISPN-10391?page=com.atlassian.jira.plugin...
]
Wolf-Dieter Fink commented on ISPN-10391:
-----------------------------------------
To prevent from this the pessimistic locking transaction need to be changed from
one-phase-commit to two-phase-commit, which is 2 times slower by committing the Tx, since
the backup owner(s) don't have locks and can't make any decision on their own.
As this would affect the consistency with the drawback of performance the default should
prefer consistency but it should be possible to switch back to the old behaviour by
configuration.
Possible loss of (pessimistic) lock if the lock owner is expelled
from the cluster and merged later
---------------------------------------------------------------------------------------------------
Key: ISPN-10391
URL:
https://issues.jboss.org/browse/ISPN-10391
Project: Infinispan
Issue Type: Enhancement
Components: API
Reporter: Wolf-Dieter Fink
Priority: Major
In case of pessimistic locking the lock is freed if the lock-owner is expelled from the
cluster.
The cluster is able to get a lock for the entry even if the original lock-owner is still
alive (but not longer a member of the cluster)
In this case there is a possibility for an inconsistency after the cluster is merged.
The two scenarios are
1) one or more nodes are disconnected to the others by network issues
2) one node is blocked by a full GC ( or suspended for another reason)
The first case must be handled by enable partition handling and set a merge policy to
solve the conflict.
The second one is not handled by partition handling and here it is possible that the
remaining cluster will get the lock and changed the entry until the original owner is
merged back, and due to the 'stop the world' pause continue and change the entry
based on the old state without failure - and this will cause unexpected inconsistent
results.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)