Hi Semyon,
we are using Ignite 2.8.1. That being said, could Ignite really be using
some behind the scenes optimization which allows for a value instance to
be re-used between multiple EntryProcessor runs?
Kamil
On 5/17/21 11:45 AM, Данилов Семён wrote:
I tried reproducing your issue but with no avail. What version of Apache Ignite
do you use?
Kind regards, Semyon.
17.05.2021, 11:03, "kimec.ethome.sk" <[email protected]>:
Hi Semyon,
the cache configuration is:
CacheConfiguration<Long, HashMap<String, String>> cc = new
CacheConfiguration<>();
cc.setName("fancyCache");
cc.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cc.setCacheMode(CacheMode.PARTITIONED);
cc.setBackups(1);
cc.setRebalanceMode(CacheRebalanceMode.SYNC);
cc.setPartitionLossPolicy(PartitionLossPolicy.READ_WRITE_SAFE);
cc.setReadFromBackup(false);
Kamil
On 2021-05-17 09:06, Данилов Семён wrote:
Hello, Kamil!
Could you please provide your cache configuration?
Kind regards, Semyon.
17.05.2021, 09:10, "kimec.ethome.sk" <[email protected]>:
Greetings,
we have recently run into a concurrency issue in an entry processor.
Suppose we have a cache that is IgniteCache<Long, HashMap<String,
String>>.
Entries in this cache are added and modified solely via
EntryProcessors.
Now suppose that the cache contains a value for key 1L - a map with
several key value pairs.
Next suppose, we execute the same entry processor for the key 1L TWICE
at the very same time on the same value.
Up until now my understanding was that since the HashMap is stored
offheap, each entry processor would get it's own deserialized copy of
the HashMap for modification and Ignite would then orchestrate the
update of the value (serializing/deserializing the value to offheap
reagion).
However, what we see in our test case is that both entry processor
"executions" receive the same deserialized HashMap and thus the
modification of the HashMap in both processors at the same time causes
java.util.ConcurrentModificationException.
I would expect this kind of behaviour in case the HashMap was stored
on
regular Java heap but if the value is deserialized from offheap
region?
Is my logic correct? I am trying to wrap my head around this but does
this mean that any complex datastractures stored in must require
separate locking?
Thanks!
Kamil
