[infinispan-issues] [JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time

[Pedro Ruivo (JIRA)]

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

Work on ISPN-2504 started by Pedro Ruivo.

> WriteSkew check fails for entries which are inserted first time
> ---------------------------------------------------------------
>
>                 Key: ISPN-2504
>                 URL: https://issues.jboss.org/browse/ISPN-2504
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 5.2.0.Beta3
>            Reporter: Radim Vansa
>            Assignee: Pedro Ruivo
>             Fix For: 5.3.0.Final
>
>
> If optimistic locking and write skew check are configured and there are two concurrent transactions performing
> {code}
> read(key) -> null
> write(key, value)
> {code}
> one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
> {code}
> EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
> if (versionSeen != null) entry.setVersion(versionSeen);
> {code}
> As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.

--
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