0672322331

Configuration Data

This article is excerpted from Chapter 4, "Adding Debugging Support," of Designing for .NET Enterprise Design with Visual Basic .NET and SQL Server 2000 by Jimmy Nilsson, Sams Publishing (ISBN 0672322331).

***

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.

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.

Dealing with Configuration Data in VB6

When we wrote COM+ components in VB6, they were Single-Threaded Apartment (STA) components. This meant that in one specific STA, only one method could run at the same time. To get multitasking, several STAs were available at the same time for a process. In the case of the COM+ server application, there were approximately ten STAs multiplied by the number of processors in the machine. Assume that you were using a machine with only one processor; your COM+ server application would then have had approximately ten threads. Each thread would have had its own public data—that is, global variables, module-global variables, and static variables (but not member data). The public data was stored in Win 32's Thread Local Storage (TLS).

This implementation could be a major problem in some situations. Developers who didn't know that global variables were local to threads and shared between users created horrible, hard to find bugs, because several users were sharing the global data. Yet the global data wasn't completely shared; there were several (say, ten) instances of it.

On the other hand, global data per thread could sometimes also be a great benefit. Even though it was an implementation detail that could change "anytime," I actually based some solutions on this very situation. The typical example was purely configuration data. When the first request came in to a newly started COM+ server application, it was possible a connection string was needed. Then a global variable was investigated to see whether it had been initialized. If not, the connection string was read—for example, from the Registry—and the value was put in the global variable. The next time a request for that very thread made the same investigation, the connection string was found and there was no need to read the Registry again. The nice thing with the solution was that it never introduced any wait states, because each thread had its own data and didn't have to wait for any other thread, which was very efficient. (The main drawback was that you had the data loaded in several instances in memory, which could be a problem in a situation where you wanted to refresh the data for all the threads at the same time, or if the data was large. If so, you wasted memory.)

When you write COM+ components in .NET, you get free-threaded components, but there is a technique to get a similar solution to that in VB6. Before I start the discussion about how to deal with this in .NET, I'd quickly like to point out two important design decisions—the design perspective and centralization.

The Design Perspective

First, remember that in this book we are discussing writing serviced components, and it is from this perspective that I need the ability to refresh the values on-the-fly. For an EXE, this is not usually a problem; it's just a matter of restarting the EXE. However, restarting a COM+ server application will often affect many users.

Because I'm talking about serviced components, this also means that I have more options for how to deal with the configuration data.

Centralization

You probably know by now that I'm very fond of centralizing code. I feel the same when it comes to accessing the configuration data. When a method needs configuration data, the method should just call another method, probably a Shared one, to find the needed data. The mechanism that is used should be completely transparent to the calling method.

Now that we've looked at these two important design decisions, let's get down to the nitty gritty. You'll see that I have divided the solution options I'm about to discuss into two parts. The first part discusses how to store the configuration data persistently, and the second part discusses how to access the configuration data from transient storage. I'll start with the first part—persistent storage.

Persistent Storage

There are many techniques from which to choose. The following is a list of a number of them, although the list is not exhaustive:

• Using the usual database

• Using the Registry

• Using Active Directory

• Using Object Construction (OC)

• Using the .config file

Let's discuss each of these techniques a little further. When you read this discussion, please keep in mind that it's not my intention that the persistent storage should be hit each time the configuration data is needed, but rather it should only be hit once or at least infrequently. (The second part of the solution, how to access the configuration data in transient storage, will further explain this.)

Using the Usual Database

The first technique, using the usual database for holding configuration data, might seem a bit strange, but this is often a really good idea. The good thing about it is that you have one centralized place for the stored configuration data, even if you have a cluster of application servers. You also have the protection of transactions if that is a requirement for you in this case.

One drawback could be that you waste some scarce resources when you have to hit the database for fetching configuration data too. This is not usually a problem, because you will rarely hit persistent storage for configuration data, but it's still something to think about.

I know, I know. Storing connection strings in the database is not a good solution, at least not if the connection strings describe how to reach the database.

Using the Registry

I have to confess that I used .ini files long after the Registry was introduced, but after a while I started to like the solution that the Registry represents. (Sure, I see the problems with it, too, but I still like it.) As you know, Microsoft has now more or less put the Registry on the legacy list and you're not supposed to use it anymore, mainly because it creates a more difficult deployment situation compared to using .config files instead, for example.

You will normally use the Registry class in the Microsoft.Win32 namespace as the entry point when working with the Registry in .NET.

Using Active Directory

You can think of Active Directory as the "Registry," but it spans all the machines in your network and all the information found on all machines. For many developers, it has become a popular place for storing connection strings and similar items.

It was hard to work with Active Directory (or rather ADSI) from VB6, but it's now much easier in .NET. You start by using the DirectoryEntry class of the System.DirectoryServices namespace for finding information in the Active Directory.

Using Object Construction (OC)

COM+ 1.0 made it possible to store a string in the COM+ catalog for a specific component and then retrieve that value when an object of the component was activated. This is still a useful and viable solution for serviced components. As you will see in the next section, I see OC both as a solution for the persistent storage and also as an access mechanism. However, you can also use it just as a persistent storage mechanism so that when you find that you need to read the value from persistent storage, you instantiate an object of the component that is using OC, grab the value, and store it in transient storage.

Listing 4.26 shows code that illustrates how OC can be used for serviced components. As you can see there, I override the Construct() method, and the parameter called constructString is the string that can be changed in the Component Services Explorer.

Listing 4.26 Example Showing How to Use OC in a Serviced Component

Imports System.EnterpriseServices
<ConstructionEnabled _ (Default:="Hello world")> _
Public Class OcTest
  Inherits ServicedComponent
  Private m_Data As String

  Public Overrides Sub Construct _   (ByVal constructString As String)
    m_Data = constructString
  End Sub

  'And some more methods...

End Class

Using the .config File

.config files are files in XML format for holding configuration data. They were introduced in .NET as a solution for helping with XCOPY deployment. (With XCOPY deployment, a single XCOPY command deploys an application at another server. There are no Registry settings that have to be written, no registrations of DLLs, and so on.)

.config files can be used for configuring the built-in tracing solution in .NET, as well as your own tracing solution.

Unfortunately, .config files don't work so well with serviced components. .config files are for EXEs, rather than DLLs, and that is pretty natural. Consider a DLL that is shared by several EXEs. It should probably be possible to use different settings for each EXE. So far, so good. The problem is that COM+ server applications are executed by the surrogate EXE called Dllhost, and there is only one EXE for all COM+ applications, so it's problematic to use the settings for, say, built-in tracing in the .config file. It's also the case that Dllhost isn't written in managed code, and it doesn't know that it should load a .config at all. This is why it's also problematic to use the System.Configuration namespace. Finally, you will have to keep the .config file in the same directory as the Dllhost EXE, and it's located in your system32 directory. So much for XCOPY deployment.

Instead, I have decided to use a custom approach for reading .config files from COM+ applications. I use the format of .config files, but I give them the name of the DLL to which they belong (same value as for exeOrDll constant). The .config files will then be stored in one specific directory. I have decided to use c:\complusapps. Then I use custom code for parsing the .config files, so this approach is quite easy after all.

Access Mechanism (and Transient Storage)

You also need to think about how to access the configuration data. You can, of course, go to the persistent storage each and every time, but this is probably too costly if you need to go there often. Therefore, the following are a few techniques that I'd like to discuss for providing an access mechanism to transient storage. (Note that this list is not exhaustive.)

• Using the Shared Properties Manager (SPM)

• Using Object Construction (OC)

• Using the Shared (static) member

• Using the ThreadStatic attribute

• Using Object Pooling (OP)

Once again, let's look at each of these techniques in detail, starting with the SPM.

Using the Shared Properties Manager (SPM)

The Shared Properties Manager (SPM) is an old, faithful component service that is still around. You can use it from your serviced components as a dictionary object to store keys and values, similar to the Application object in ASP.NET. However, the SPM can group the keys in property groups.

The programming model of the SPM is a bit different from other dictionary objects, but it's still quite simple. You can see a sample in Listing 4.27, where a value is read from the SPM (or written if it wasn't found in the SPM).

Listing 4.27 Reading a Value That Is Stored in the SPM

Imports System.EnterpriseServices
Public Class SpmTest
  Inherits ServicedComponent

  Public Function Test() As String
    Dim theExist As Boolean
    Dim aManager As New SharedPropertyGroupManager()

    Dim aGroup As SharedPropertyGroup = _
    aManager.CreatePropertyGroup("MyGroup", _
    PropertyLockMode.SetGet, _
    PropertyReleaseMode.Process, theExist)

    Dim aProperty As SharedProperty = _
    aGroup.CreateProperty("MyProperty", theExist)

    If Not theExist Then
      aProperty.Value = Now.ToString()
    End If
    Return aProperty.Value.ToString()

  End Function
End Class

Using Object Construction (OC)

In the previous section, I talked about OC as a mechanism for persistent storage, but it is also a mechanism for accessing transient storage. Refer toListing 4.26 for a code sample.

Using a Shared (Static) Member

Using a Shared member variable is by no means specific to serviced components, of course. It's a simple and efficient mechanism. Its main problem is that you only have one single instance that is shared by all users and their components, which can lead to concurrency conflicts when the value isn't read-only. Because of this, you have to protect the value by writing thread-safe code. This will result in wait states in a highly stressed environment when the Shared member is to be used all the time. Most often, it won't cause you any problems, but in some situations—as I said, under extreme load—it might be a show-stopper.

To get a cheaper locking solution, you can implement a ReaderWriter lock instead. That means that there might be several readers at the same time, but only one writer. Do you get a déjà vu from the database area? You can find more information about how to implement a ReaderWriter lock in the .NET online help.

Using the ThreadStatic Attribute

It's possible to use TLS in .NET too, so that each thread will have it's own local data. It's easily achievable by just marking a Shared variable with the ThreadStatic attribute.

This will mean that you will have as many instances of the data as you have threads. There will be no blocking, because each thread will the data it needs. This might also mean a problem for you because you waste memory, but that is most often not the case for configuration data.

Using Object Pooling (OP)

The final technique that I'd like to discuss for providing an access mechanism to transient storage is using Object Pooling (OP) in serviced components. If you still remember the technique of thread-specific global variables from the days of VB6 (and which I discussed earlier in this section about configuration data), OP is the technique that comes closest to that solution. Not that pooled objects are tied to a specific thread, but you will have a pool of n number of objects with OP, so that you can avoid the situation of several simultaneous requests of the same value leading to wait states. On the other hand, the larger the pool, the larger the amount of used memory, of course.

However, while it is an advantage that several instances minimize contention, it's a disadvantage if it's necessary for all instances to have the same values all the time. If it is necessary, you'd better use one single value instead (unless it's not a "fetch once, use many times" type of data).

Summary of Persistent Storage and Access Mechanisms

Not all access mechanisms can be used with all persistent storage mechanisms. Table 4.3 presents the possible combinations.

Table 4.3 Possible Combinations of Access Mechanisms and Persistent Storage Mechanisms

As you see in Table 4.3, only OC is a bit inflexible as an access mechanism because it is so closely related to its storage. You can let the users affect OC as an access mechanism by using the Admin API for COM+ to change the stored value, but it is sort of a hack. At least, I don't think this was the way OC was supposed to be used.

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 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 B objects.