To keep your current Singleton, move whatever code loads up all the state in the Singleton from a constructor to an init() method. Then you can call the init() method any time you like. I'd expect it to create a new HashMap and populate it from scratch. During the brief time it's reloading, the map will be invalid for any clients. You may have to synchronize all access to the map.
Can you build your cache to "lazy load" so it knows how to load data that it doesn't have? With this you only have to empty the HashMap and let it reload itself over time. It makes the window of invalid time very short.
Finally, Singleton may not be needed here. You can get by with all static methods. I made one like this:
I called setTheRealCache in startup, avoided Singleton, gave clients the convenience of static methods, and allowed myself to plug in alternative RealCache implementations as needed. For example, one implementation has extra instrumentation, another has a different self cleaning algorithm.
The timer is one way to trigger your refresh. There are several algorithms for self-cleaning, like least recently used and time to live, which might help avoid the timer
thread. And I always make sure to have a dashboard or admin console so I can clear caches on demand any time.
[ May 21, 2007: Message edited by: Stan James ]