흐미~

Object pooling allows you to create a cache of application servers that are shared by their clients, thereby conserving resources. How this works depends on the type of remote data module and on the connection protocol.
If you are creating a transactional data module that will be installed to COM+, you can use the COM+ Component Manager to install the application server as a pooled object.
Even if you are not using a transactional data module, you can take advantage of object pooling if the connection is formed using TWebConnection. Under this second type of object pooling, you limit the number of instances of your application server that are created. This limits the number of database connections that you must hold, as well as any other resources used by the application server.

When the Web Server application (which passes calls to your application server) receives client requests, it passes them on to the first available application server in the pool. If there is no available application server, it creates a new one (up to a maximum number that you specify). This provides a middle ground between routing all clients through a single application server instance (which can act as a bottleneck), and creating a separate instance for every client connection (which can consume many resources).

If an application server instance in the pool does not receive any client requests for a while, it is automatically freed. This prevents the pool from monopolizing resources unless they are used.
To set up object pooling when using a Web connection (HTTP), do the following:

1    Locate the UpdateRegistry method of the implementation class. This method appears in the header file of your implementation unit:

static HRESULT WINAPI UpdateRegistry(BOOL bRegister)

{
  TRemoteDataModuleRegistrar regObj(GetObjectCLSID(), GetProgID(), GetDescription());
  return regObj.UpdateRegistry(bRegister);
}

2    Set the RegisterPooled flag of the regObj variable, which is an instance of TRemoteDataModuleRegistrar, to true. You will also want to set other properties of regObj to indicate how the cache of remote data modules should be managed. For example, the following code allows a maximum of 10 remote data module instances and frees them from the cache if they are idle for more than 15 minutes:

static HRESULT WINAPI UpdateRegistry(BOOL bRegister)

{
  TRemoteDataModuleRegistrar regObj(GetObjectCLSID(), GetProgID(), GetDescription());
  regObj.RegisterPooled = true;
  regObj.Timeout = 15;
  regObj.Max = 10;
  return regObj.UpdateRegistry(bRegister);
}

When using either method of object pooling, your application server must be stateless. This is because a single instance potentially handles requests from several clients. If it relied on persistent state information, clients could interfere with each other. See Supporting state information in remote data modules for more information on how to ensure that your remote data module is stateless.