Configuration Data
Techniques for dealing with configuration data are clearly useful in many situations, not only for adding debugging support.
When I refer to configuration data, I'm talking about the kind of configuration data that you need to refresh on the fly (such as enabling/disabling tracing), as well as more static configuration data such as connection strings. Before we look at how to deal with configuration data, I'd like to say a few more words about the data itself.
NOTE
It's not just possible to enable/disable tracing by changing configuration data. It is also easy, for example, to switch between different tracing implementations to be used by changing the content of the configuration data.
Different Types of Configuration Data
The following are the different types of configuration data:
- Fetched once, used many times
- Fetched every now and then, used many times
- Fetched each time it is used
I just mentioned connection strings, and this kind of configuration data is a typical example of "fetched once, used many times." When your server application is running, it's perfectly fine to say that, for the application to refresh the connection string to work with another database server instead of the current one, you have to shut down the server application so that the next request will lead to the connection string being read again (and the new value is then found).
The second category, "fetched every now and then, used many times," can be exemplified with settings for configuring tracing. You don't usually want to shut down the server application simply to change the filter for tracing or to activate tracing. Instead, reading the configuration data from persistent storage is often good enough, say, once a minute, and all requests for the configuration data are serviced with cached data in this time.
Finally, the third category, "fetched each time it is used," is not actually a common type of configuration data (at least, I can't think of an example). If you encounter this situation, it might be a good idea to think twice about whether this is really configuration data or session data, user data, or application data. Such data that must be fetched from persistent storage each time it will be used often enjoys living in the database.
There are several techniques to choose from when dealing with these different types of data. However, I'd like to start with a short discussion about how I solved the problem of dealing with configuration data in the old days of VB6.