Sorry, I replied a little too fast. It is true that my original suggestion would not work and I agree that it would be better to copy the map in `commitSync` (that's why I suggested it in my email). Please file a JIRA. However, that doesn't solve your immediate issue. More inline.
On Thu, Feb 2, 2017 at 12:37 PM, Jan Lukavský <je...@seznam.cz> wrote: > - if I remove the `Collections.synchronizedMap` from the `commitMap` I > get unsynchronized map and therefore the asynchronous writes to this map > would result in undefined state > Yes, I had assumed that there would be synchronization in the code that does this, but I realise now that this assumption was incorrect. - if I remove the manual synchronization then there is a race condition > between the call to `commitSync` and `clear` of the `commitMap` - some > other thread could write to the `commitMap` between calls to `commitSync` > and `clear` and therefore the update to the map would be lost - this is the > same reason why I cannot use ConcurrentHashMap, because there would be no > synchronization between commiting the map and clearing it > I hadn't quite understood this. So the asynchronous code continues to update the map, I see. Regarding your suggested fix, the required change is not to hold a lock to the map passed to `commitSync`, so cloning should be enough to fix the issue. So do I understand correctly that moving the commitSync out the synchronized block is an optimisation (i.e. the async threads can update the map while the commitSync is happening)? Ismael
