[infinispan-issues] [JBoss JIRA] (ISPN-3095) Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking

[Adrian Nistor (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Nistor updated ISPN-3095:
--------------------------------

    Description: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backups to apply the update (unless write skew check is enabled). Not doing so might lead to a situation where the key is not available locally yet (state transfer in progress) and will be fetched remotely from another owner that has already executed the conditional command. The previous value check would fail then. The check adds little value on backup owners so it should not be done at all.  (was: TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backup to apply the update (unless write skew check is enabled).)

    
> Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-3095
>                 URL: https://issues.jboss.org/browse/ISPN-3095
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core API, Distributed Cache
>    Affects Versions: 5.2.5.Final
>            Reporter: Adrian Nistor
>            Assignee: Adrian Nistor
>             Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backups to apply the update (unless write skew check is enabled). Not doing so might lead to a situation where the key is not available locally yet (state transfer in progress) and will be fetched remotely from another owner that has already executed the conditional command. The previous value check would fail then. The check adds little value on backup owners so it should not be done at all.

--
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: http://www.atlassian.com/software/jira