This chapter is from the book
This chapter is from the book
This chapter is from the book
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 10 STAs multiplied by the number of processors in the machine. Assume that you were using a machine with two processors; your COM+ server application would then have had approximately 20 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, 20) 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 that 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 without doing a shutdown of the COM+ application, 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.