You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/11/03 00:28:00 UTC

[jira] [Commented] (GEODE-8672) Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost

    [ https://issues.apache.org/jira/browse/GEODE-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225028#comment-17225028 ] 

ASF subversion and git services commented on GEODE-8672:
--------------------------------------------------------

Commit e695938dff4b39f1755c707e81e1eb7e2e143fe0 in geode's branch refs/heads/develop from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e695938 ]

GEODE-8672: No need in token mode if concurrencyChecksEnabled (#5691)

  * The DESTROYED token is only needed to prevent concurrent destroy op
    is lost in GII. If concurrency checks are enabled, the version tag
    should be able to prevent the destroy op being lost.



> Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-8672
>                 URL: https://issues.apache.org/jira/browse/GEODE-8672
>             Project: Geode
>          Issue Type: Bug
>          Components: regions
>            Reporter: Eric Shu
>            Assignee: Eric Shu
>            Priority: Major
>              Labels: pull-request-available
>
> In a newly rebalanced bucket, while GII is in progress, a transactional destroy is applied to cache. There is a logic that it should be in token mode and leaves the entry as a Destroyed token, even though the version tag of the entry indicates that it has the correct version.
> However, at end of the GII, there is a cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed entries – this wipes off the entry version tag information and cause the subsequent creates starts fresh with new version tags.
> This could leads to client server data inconsistency as the newly created entries will be ignored by the clients as the newly created entry has lower version number while client has high ones.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)