You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2016/02/10 20:32:18 UTC

[jira] [Updated] (GEODE-698) Concurrent transactional and non transactional operations on the same key can result in inconsistency

     [ https://issues.apache.org/jira/browse/GEODE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darrel Schneider updated GEODE-698:
-----------------------------------
    Component/s: transactions

> Concurrent transactional and non transactional operations on the same key can result in inconsistency
> -----------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-698
>                 URL: https://issues.apache.org/jira/browse/GEODE-698
>             Project: Geode
>          Issue Type: Bug
>          Components: transactions
>            Reporter: Dan Smith
>            Assignee: Swapnil Bawaskar
>         Attachments: GEODE-698-test.patch
>
>
> The basic issue here is that the locks obtained by the transactions are not the same as the locks that non transactional operations use. So a non transactional operation can overlap with a transaction that is in the middle of committing the same key.
> Here are the details:
> 1. Thread 1 - Do a put in a transaction on the primary. Start the commit
> 2. Thread 1 - In TXState.commit, we call apply changes, which updates the local cache.
> 3. Thread 2 - do a query on the primary and find the key.
> 4. Thread 2 - Do a destroy on the same key. There is no lock that blocks this destroy, so it goes through and is applied to all members.
> 5. Thread 1 - Let TXState.commit continue. It creates a TXCommitMessage and sends it
> 6. Thread 1 - The TXCommit message applies the entry to the secondary. At this point the secondary has the entry but the primary has removed it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)