Timeline for Can my cache be more thread safe?
Current License: CC BY-SA 3.0
10 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Mar 14, 2016 at 11:34 | comment | added | Reinstate Monica |
@bowmore You are right. Those two puts blended into one when I looked at them and I didn't realize that they were in cache values. Those BasicDBObject.put s are definitely a problem.
|
|
Mar 14, 2016 at 9:54 | comment | added | I am not smart | Thanks for all the feedback. I have an updated version here: pastebin.com/rDmmpTL2 | |
Mar 14, 2016 at 7:33 | comment | added | bowmore |
in insertOverWrite you do : cache.get(key).get(Operation.OVERWRITE).put(fieldName, fieldValue); ; without the write lock, that put is not synchronized. The containing ConcurrentHashMaps don't help you here, as you're outside their get() methods. Volatile doesn't help you either.
|
|
Mar 14, 2016 at 7:15 | comment | added | I am not smart | @bowmore doesn't making the cache volatile solve this issue? The map that the DBO is contained in is also concurrent, so the writes should be locking? | |
Mar 14, 2016 at 6:50 | comment | added | bowmore | BasicDBObject (if it is MongoDb's) is a subclass of LinkedHashMap and therefore not thread safe. I don't think you can forego the locks. | |
Mar 13, 2016 at 23:44 | comment | added | Reinstate Monica | @poixen For #3, use Operations, not strings, and switch on the Operation. | |
Mar 13, 2016 at 18:16 | comment | added | I am not smart | Thanks for the excellent feedback. I have added most of the feedback to the code. Though you can not use comment #3, as it is not a compile time expression. | |
Mar 11, 2016 at 17:50 | history | edited | Reinstate Monica | CC BY-SA 3.0 |
added 215 characters in body
|
Mar 11, 2016 at 17:41 | history | edited | Reinstate Monica | CC BY-SA 3.0 |
added 176 characters in body
|
Mar 11, 2016 at 17:36 | history | answered | Reinstate Monica | CC BY-SA 3.0 |