[infinispan-issues] [JBoss JIRA] (ISPN-5720) putForExternalRead may not acquire lock in invalidation mode

[Radim Vansa (JIRA)]

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

Radim Vansa commented on ISPN-5720:
-----------------------------------

The more I think about this, invalidation mode should always acquire locks, there the notion of primary owner does not make sense since we just broadcast the invalidation, not going to primary first.

> putForExternalRead may not acquire lock in invalidation mode
> ------------------------------------------------------------
>
>                 Key: ISPN-5720
>                 URL: https://issues.jboss.org/browse/ISPN-5720
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 8.0.0.Final
>            Reporter: Radim Vansa
>
> Usual PutKeyValueCommands go to primary owner to acquire the lock, and then they can safely modify the entry on backup owners.
> In invalidation mode, the puts are not distributed (there's no xDistributionInterceptor) and InvalidationInterceptor has special switch for PFER that lets it through. That way, when the PFER is executed on non-primary node, it gets executed without lock being held, potentially overwriting another operation.
> The same issue is with all write commands that get invoked with LOCAL_MODE flag. Fixing this is troublesome, since we don't want to lock keys on backup owners too (that would not cause deadlock if done *after* acquiring lock on primary, but it would incur performance hit). However, for PFER specifically we could use putIfAbsent operation on datacontainer during entry commit (this was [~dan.berindei]'s idea).
> This could be even generalized to do a compute() check on the container, verifying equality of stored vs. wrapped value, but I am not sure about the consequences.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)