0

Inside an application scoped bean, we have a hashmap that holds some counters for each user (just transient, not saved anywhere) each user is represented by it's own sub-hashmap:

Map<String, Map<String, Object>> userValues = new HashMap<String, Map<String, Object>>();

for instance:

application.getUserValues().get(user.id).put("lastAction", new Date());

Every Sub-Hash-Map is initialized empty (single-threaded) during startup. Each Sub-Hash-Map is guaranteed to ONLY be modified ("put", never remove) and not beein replaced.

Write Access on the Sub-Hash-Maps is guaranteed to happen only by a single thread at any time, but as the example above shows, there could be 2 threads modifying two different sub-maps at the same time)

We are not using a SessionScope, because some of the information needs to be exposed to other sessions as well (i.e. the Teamlead should be able to see the values)

Until now, there never have been Concurrency-Issues, but Concurrency is always hard to "test" properly as it mainly depends on the overall system-load and actions beeing performed around the same time.

Following this thread: Is ConcurrentHashMap.get() guaranteed to see a previous ConcurrentHashMap.put() by different thread? I assume, that using Concurrent Hashmaps for the inner hashmap would perfectly ensure that there are no problems using put and get on the same map at the same time from different threads.

So it would be better to use Map<String, ConcurrentHashMap<String, Object>> right?

Would it also be required to use a ConcurrentHashmap for the "outer" map? That map never changes, only operation on that one will be get().

Community
  • 1
  • 1
dognose
  • 20,360
  • 9
  • 61
  • 107

1 Answers1

1

If your same submap is accessed by multiple threads and they do write as well to the map then ConcurrentHashMap makes sense. If they just read the data while writing just once initially even before multiple threads start say initialization for e.g., then you dont need concurrentHashMap.

Similarly you need to think of outer map as well.

SMA
  • 36,381
  • 8
  • 49
  • 73
  • write to the submaps is ensured to be exclusive. However another thread could read on the same map. i.e. `application.getUserValues().get("47fjkgfg4").put("lastAction", new Date());` and `application.getUserValues().get("47fjkgfg4").get("lastAction);` could appear at the same time from different threads. – dognose Mar 15 '15 at 12:34
  • Yes then i would suggest you use ConcurrentHashMap. – SMA Mar 15 '15 at 12:35
  • thx a lot. Assumed that as well. But for the outer one, where only get is performed at any time, there is no need i'd say? – dognose Mar 15 '15 at 12:36
  • Definately. If you just initialised them once and you have multiple readers then you just dont have to think of threading. – SMA Mar 15 '15 at 12:42