Prasad,
> Can you please answer following questions? > 1) The significance of the nodeOrder w.r.t Grid and cache? > Node order is a unique integer assigned to a node when the node joins grid. The node order is included into GridCacheVersion to disambiguate versions generated on different nodes that happen to have the same local version order. > 2) When does it change? > Node order does not change during the node lifetime. If two versions have different node order, it means that the versions were generated on different nodes. > 3) How it is important w.r.t. transaction? > GridCacheVersion is used to detect concurrent read-write conflicts as I described in the previous message, as well as for data rebalance. > 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? > Yes, this is perfectly fine to update replicated and transactional caches inside one transaction. >From the debug output that you provided we can infer that the version of both entries have changed for both caches before transaction prepare phase. I would back up Alexei here: * How do you ensure that there are no concurrent updates on the keys? * How many retry attempts did you run? * Are your caches in-memory with eviction policy? * Do you have TTL enabled for either of the caches? * Do you have a 3rd-party persistence and read-through and write-through enabled for either of the caches? * Can you check if the issue reproduces if you set -DIGNITE_READ_LOAD_BALANCING=false system property? --AG
