EHC ❯ Fix field memory visibility issues in CacheManager
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
cdennis
-
Reporter: amiller
-
October 27, 2009
-
1
-
Watchers: 2
-
July 27, 2012
-
November 04, 2010
Description
Many fields in core classes are read and written by multiple threads but don’t properly use either synchronized or volatile. These fields are subject to visibility issues due to the Java Memory Model and should be made volatile or read/written under synchronization.
CacheManager fields:
- name - read/written w/o synchronization. make volatile.
- status - read/written w/o synchronization. make volatile.
- cacheManagerPeerProviders - could be made final if configure() added ConfigurationHelper.createCachePeerListeners() return instead of replaced
- cacheManagerPeerListeners - could be made final if configure() added ConfigurationHelper.createCachePeerListeners() return instead of replaced
- cacheManagerEventListenerRegistry - should be final
- shutdownHook - this is a whole separate topic
- defaultCache - created during construction. hard to make final, but ok as is
- diskStorePath - created during construction. hard to make final, but ok as is
- mbeanRegistrationProvider - looked up during construction. hard to make final, but ok as is.
- cacheManagerTimer - created during construction. hard to make final, but ok as is
- terracottaStoreFactory - created during construction. hard to make final, but ok as is
I think there is some possible restructuring that could happen here to make many of these fields final by pulling init() into the base constructor and possibly returning the constructed objects from configure() instead of setting fields directly.
Comments
Fiona OShea 2010-06-15
Fiona OShea 2010-08-11
Is this still an issue?
Moving to Fremantle for consideration. If this is a big issues please assign to Issue Review Board