[infinispan-issues] [JBoss JIRA] (ISPN-10391) Possible loss of (pessimistic) lock if the lock owner is expelled from the cluster and merged later

[Wolf-Dieter Fink (Jira)]

    [ https://issues.jboss.org/browse/ISPN-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756798#comment-13756798 ] 

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)