EHC ❯ CacheManager.create() always calls ConfigurationFactory.parseConfiguration() which causes poor performance loading existing caches
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
cdennis
-
Reporter: karlvr
-
February 08, 2012
-
1
-
Watchers: 5
-
August 13, 2012
-
February 27, 2012
Description
CacheManager.create() is used to create and or simply return the singleton CacheManager instance. As such it suggests that it can be called cheaply to get an existing singleton CacheManager.
In revision 4719 on 22nd September 2011 it was modified so that it always calls ConfigurationFactory.parseConfiguration(), I believe so that it can find the name of the cache manager from the configuration.
This means that every call to CacheManager.create() creates a SAXParser and parses the configuration file. Which is substantially slower than the pre-4719 implementation which kept a reference to the singleton.
I believe this is a serious performance regression. I’m sorry I’m not sure of the resolution as I don’t completely understand the subsequent changes. We are working around this in our environment, in the meantime, by caching the result of CacheManager.create() elsewhere.
Comments
Alexander Snaps 2012-02-09
Chris Dennis 2012-02-14
I’ve created a crucible review (http://svn.terracotta.org/fisheye/cru/CR-428) for the initial (non-test code) portions of this fix.
Here is my take on this: We did screw up with the contract of those methods and that’s wrong. Since we do require named CM now, we should introduce a CM.getInstance(String) and deprecate the one w/o a name provided. The new method would return or create the CM based on the name passed in. To not break existing code out there, the “old” CM.getInstance() should return the “singleton” CM. If not present, create it. When created it is being created from the default location: /ehcache.xml, based on the TCCL (or net.sf.ehcache.config.ConfigurationFactory’s CL). Whatever that CM’s name should then be considered the “Singleton” cache. CM.create() would behave as currently _and_ replace the “singleton CM” if required. If the resulting CM’s name does exist already, we throw. Even though I admit this is not _entirely_ correct, it probably is the closest to what people have been doing so far with these methods… These are just my opinions and not those of my employer ;-) Any other idea ? Am I missing something else ?