[jira] [Commented] (IGNITE-3464) Possible race between partition exchange and prepare/finish requests

["Alexey Goncharuk (JIRA)" <ji...@apache.org>]

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

Alexey Goncharuk commented on IGNITE-3464:
------------------------------------------

I think we should complete partition release future for DHT local transactions only when we received ACKs from backup nodes.
No additional messages should be sent for FULL_SYNC mode, just modify the wait logic.
For PRIMARY_SYNC mode we should send asynchronous finish responses in batches when there is no exchange and send finish responses immediately when exchange is in progress.

> Possible race between partition exchange and prepare/finish requests
> --------------------------------------------------------------------
>
>                 Key: IGNITE-3464
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3464
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: ignite-1.4
>            Reporter: Alexey Goncharuk
>
> Consider the following scenario:
> Two nodes A (coordinator), B. Node C is joining the grid. Current topology version is 2.
>  - Node A starts a transaction on version 2 and sends a prepare request to node B
>  - Discovery event happens on node A. Exchange future is created, captures the transaction and waits for this transaction to finish.
>  - Discovery event happens on node B. Exchange future is created, but since there is no transaction on this node (the request has not been processed yet), partition release future is completed and exchange waits for an ACK from coordinator.
>  - Prepare request is processed on node B
>  - Node A commits the transaction locally, partition release future is completed. Both finish request and exchange message are sent to the node B.
>  - Node B processes the exchange message first and completes exchange.
>  - Node C starts rebalancing from node B and acquires stale value of the key which was supposed to be updated in the transaction.
>  - Node B processes finish request and commits the transaction.
> As a result, node B and C have different values stored in the cache.



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