Race condition and conflicts during cache modifications?

[humenius <co...@humenius.me>]

Hello everyone,

I have a few questions:

1) How are cache entry merge conflicts handled? Does the newer topology
version of the entry always win? Can the cache conflict resolver be changed
to a custom implementation?

2) Imagine a *cache* which uses key=String and *value=List* in *replicated*
mode with *full sync*. What happens if an existing cache entry is modified
during a rebalance caused by a newly joined node? Is there a kind of
"queuing" system? As far as I have understood, any kind of cache
transactions are blocked until synchronization has completed.

3) Prevailing on the environment as mentioned in 2): Let's say I add
something to the top of the list and then remove something from the bottom
of the list. Can there be a case of race condition where two cache
modifications happen but the newer one comes before the older one? If so,
will the old modification be dismissed? (thus leading to only having the
bottom of the list modified)

4) Can Google's Multimap be used as a cache entry value? I noticed that when
using their multimap implementation, a ClassCastException occurs where the
class references to itself (e. g. ClassA cannot be casted to ClassA -
similar to class loader issues)

Thanks in advance!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/