Prasad,
The current version in the entry is checked agains the version which was
read from the very same entry, so with absence of concurrent updates the
version will be the same.
>From your description, I think there might be a concurrent read for the key
that you clear which loads the value on
Hi,
* How do you ensure that there are no concurrent updates on the keys?
[Prasad]: The cache for which it is failing is kind of bootstrap cache
which changes very rarely. I made sure that I was the only one working on
this system while debugging the issue.
The cache for which it is failing is RE
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 th
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
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 GridDhtTx
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
