Hello! Ignite indeed has such optimizations but I don't see them enabled in your configuration so perhaps it's a bug. I still have trouble reproducing your issue, so could you please send a minimal reproducer?
Kind regards, Semyon. 19.05.2021, 06:12, "Kamil Misuth" <[email protected]>: > 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
