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