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
