Hi Alexey, Key value is not getting changed concurrently, I am sure about it. The cache for which I am getting the exception is kind of bootstrap data and it changes very rarely. I have added retry logic in my code and it failed every time giving the same error .
Every time if fails in GridDhtTxPrepareFuture.checkReadConflict -> GridCacheEntryEx.checkSerializableReadVersion method and I think it fails due to the change in value of nodeOrder. This is what I observed while debugging the method. This happens intermittently. I got following values while inspecting GridCacheVersion object on different nodes. Cache : Addons (Node 2) serReadVer of entry read inside Transaction: GridCacheVersion [topVer=194120123, order=4, nodeOrder=2] version on node3: GridCacheVersion [topVer=194120123, order=4, nodeOrder=1] Cache : Subscription (Node 3) serReadVer of entry read inside Transaction: GridCacheVersion [topVer=194120123, order=1, nodeOrder=2] version on node2: GridCacheVersion [topVer=194120123, order=1, nodeOrder =10] Can you please answer following questions? 1) The significance of the nodeOrder w.r.t Grid and cache? 2) When does it change? 3) How it is important w.r.t. transaction? 4) Inside transaction I am reading and modifying Replicated as well as Partitioned cache. What I observed is this fails for Replicated cache. As workaround, I have moved the code which reads Replicated cache out of transaction block. Is it allowed to read and modify both replicated and Partitioned cache i.e. use both Replicated and Partitioned? Thanks, Prasad On Thu, Feb 27, 2020 at 6:01 PM Alexey Goncharuk <alexey.goncha...@gmail.com> wrote: > Prasad, > > Since optimistic transactions do not acquire key locks until prepare > phase, it is possible that the key value is concurrently changed before the > prepare commences. Optimistic exceptions is thrown exactly in this case and > suggest a user that they should retry the transaction. > > Consider the following example: > Thread 1: Start tx 1, Read (key1) -> val1 > Thread 2: Start tx 2, Read (key2) -> val1 > > Thread 1: Write (key1, val2) > Thread 1: Commit > > Thread 2: Write (key1, val3) > Thread 2: Commit *Optimistic exception is thrown here since current value > of key1 is not val1 anymore* > > When optimistic transactions are used, a user is expected to have a retry > logic. Alternatively, a pessimistic repeatable_read transaction can be used > (one should remember that in pessimistic mode locks are acquired on first > key access and released only on transaction commit). > > Hope this helps, > --AG >
