[
https://issues.apache.org/jira/browse/GEODE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804466#comment-16804466
]
Dan Smith commented on GEODE-698:
---------------------------------
[~amb] Yes, that's our recommendation. But if you mix them, you don't get a
nice error message - just inconsistent data!
> 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)
