How and When to Refresh the Cached Configuration Data
Finally, it might be a problem deciding when to refresh the cached configuration data. A simple approach is to encapsulate the data so that each time there is a request for the data, you can investigate whether a certain amount of time has elapsed since the last time the date was refreshed. If so, you go to persistent storage to read the data and remember when this happened.
If you use, for example, Object Pooling for caching the data, it might be a good idea to introduce a two-phase technique so that not every object in the object pool has to go to persistent storage. Instead, you have one single pooled object (of, say, class A) that is responsible for this, and every pooled object (of, say, class B) will only go to the object of class A when they find out that it's time to refresh their data. Class A uses a similar algorithm so that it doesn't go to persistent storage each time it is called by a B instance. If you use a schema like this, you have to remember that the maximum time for different instances to be out of sync is the sum of the refresh delay of the A object and the refresh delay of one B object.