Hi Prasad. nodeOrder is local counter used for updates ordering. The version is incremented when lock is aquired for enlisted tx entry.
Are you sure where is no concurrent transaction on this replicated cache which works significant time until committed ? How long have you re-tried after getting optimistic exception ? Do you have stable topology (no concurrently failing node) when this is happens ? Do you have on-heap cache enabled ? чт, 27 февр. 2020 г. в 16:06, Prasad Bhalerao <prasadbhalerao1...@gmail.com >: > 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 >> > -- Best regards, Alexei Scherbakov
