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

["Anthony Baker (JIRA)" <ji...@apache.org>]

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

Anthony Baker commented on GEODE-698:
-------------------------------------

Wouldn't our recommendation be to use consistent operation types?  That is, all transactional or all non-transactional?  [~upthewaterspout]

> 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
>            Priority: Major
>         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
(v7.6.3#76005)