Deciding how your pool manager creates instances of objects is a key decision. Because the pool manager needs to be as free as possible to allocate an object at any time, without forcing requesters to wait until an instance has been created, how object instances are started becomes an important consideration. Let’s go over some of the options for creating object instances.
Create objects during “idle” time For this option, we would notice when our pool of a certain object class was running low as we gave out object instances, but we would log this fact for future action and instantiate new object instances only when the pool manager was not being called on to do anything else. This strategy calls for careful management of the number of free objects in the pool so that you rarely have to start new ones in response to an immediate demand. Nevertheless, using this strategy is eventually going to restrict scalability since creating an instance of an out-of-process server is a lengthy business.
In-process object servers We could have our server objects provided by in-process object servers, which are in process to the pool manager. If we did this, the instantiation hit would be much lower. A drawback of this method is that it restricts being able to easily add new object types on the fly.
Call out to create For all additions to an object type’s pool, the pool manager could call an AddNew method in another stand-alone application (an instantiator) by using an ActiveX callback or an event so that the pool manager would be informed when the object instance had been created and was available for use.
Call in to create We can make our instantiator a class within a multithreaded pool manager, in which case we can use a new thread to instantiate or to launch and use an instantiator.