Figure 2-18 shows a COM-type object model for a pool manager that might support all this.
Figure 2-18 Possible object model for a pool manager
For the pool manager top-level class, which is the root of the pool manager application, I would suggest a 32-bit out-of-process server (unless you intend to use Microsoft Transaction Server). The pool manager class should be Public and MultiUse and compiled for Unattended Execution. As to the number of threads to use, I would personally use a thread pool based on how many processors I had and how I was going to carry out my creates. An OMT (Object Modeling Technique) class diagram for it might look something like Figure 2-19.
Pool manager persistent data storage With all this information, the data that the pool manager will need to store must be kept somewhere. It can be kept in flat files in the same folder as the pool manager’s executable, in the Registry, or in a database. Each storage location has its pros and cons. Flat files are easy to manage and change, but this is a double-edged sword because it’s easy for anyone to change. The Registry is more secure, but it’s slower, less friendly, and also a higher risk, considering you could disable your whole system with an incorrect Registry setting (although I have used the Registry quite successfully). A database, even a local .MDB, would appear to be adding unnecessary complication. Logically, storage for a pool manager might look like the example shown in Figure 2-20 on page 78.
Figure 2-19 A candidate pool manager class diagram
Figure 2-20 An example of pool manager storage