[
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)