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

Anton Vinogradov commented on IGNITE-12739:
-------------------------------------------

[~vladsz83],
 Some comments

1) {{grid(0).cache("tx") and grid(1).cache("tx")}} should be always used via 
variables.

2) {{cache = grid(0).cache("tx"); cache = grid(1).cache("tx");}}
 Variables should be final. Lets name them cache0 and cache1.

3) {{assertEquals(2, grid(1).cache("tx").get(key)); assertEquals(2, 
grid(0).cache("tx").get(key));}}
Lets just check each node.

4) We should also test/fix getAll (GridPartitionedGetFuture case).

5)
{noformat}
if (forcePrimary)
    affNodes = Collections.singletonList(affNodes.get(0));

ClusterNode affNode = cctx.selectAffinityNodeBalanced(affNodes, 
getInvalidNodes(), part, canRemap);
{noformat}
See no reason to perform selectAffinityNodeBalanced when forcePrimary.
 Better to set affNode via "forcePrimary ? ... : ...".

> Optimistic serializable transactions may fail infinitely when read-through is 
> enabled
> -------------------------------------------------------------------------------------
>
>                 Key: IGNITE-12739
>                 URL: https://issues.apache.org/jira/browse/IGNITE-12739
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 2.8
>            Reporter: Alexey Goncharuk
>            Assignee: Vladimir Steshin
>            Priority: Major
>             Fix For: 2.9
>
>         Attachments: ReplicatedOptimisticTxTest.java
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> In current design it is possible that the same key-value pair will be stored 
> with different versions on primary and backup nodes. For example, a 
> read-through is invoked separately on primary backup and values are stored 
> with node local version.
> With this precondition, if an optimistic serializable transaction is started 
> from a backup node, the serializable check version is read from backup, but 
> validated on primary node, which will fail the transaction with optimistic 
> read/write conflict exception until the versions are overwritten to the same 
> value (for example, via a pessimistic transaction).
> While we need to additionally investigate whether we want to change the 
> read-through logic to ensure the same value and version on all nodes, this 
> particular scenario should be fixed by always enforcing reading from a 
> primary node inside an optimistic serializable transaction.
> The reproducer is attached. A known workaround is to disable read load 
> balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property.



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

Reply via email to