Using COM+ object pooling with Delphi 6

By: Vincent Parrett

Abstract: Delphi 6 introduces support for COM+ object pooling, which can provide significant performance improvements under some circumstances. We take a look at Delphi 6s object pooling support. By Vincent Parrett.

Typically, when a client application instantiates a COM+ object, the COM+ runtime will create a new instance of the object. When your client is done with the object, COM+ will destroy the object. This all makes for very efficient use of memory resources, and under normal loads provides quite an acceptable performance.

However, under higher loads the creation and destruction of objects can become a substantial overhead. This is especially true if your COM+ objects are themselves allocating resources, instantiating other objects, and so on.

Object pooling can help in these situations by reducing the number of times an object must be instantiated or destroyed. When pooling is in effect, a client's request for an object will kick of a search to see if there is a ready-to-use object pool for objects of the appropriate type. If so, the COM+ system will provide and activate the object. If not, COM+ will create a new object. When the client is done with the object, COM+ will not destroy the object, but will return it to the object pool so it can be reused.

To get the best out of COM+, your objects should be stateless. To make use of object pooling, they must be stateless objects.

Object pooling with Delphi 6

Supporting object pooling in Delphi 6-generated COM+ objects is simple, however there are a few things that you need to take care with:

Threading model

The first is that you must select the Both threading model, otherwise object pooling will be disabled.

If you get this wrong, don't worry -- it's easy to fix. The New Transactional Object wizard generates code that looks something like this :

  TAutoObjectFactory.Create(ComServer, TMyCOMPlusObject, Class_MyCOMPlusObject,
   tmBoth); // make sure this is tmBoth.


COM+ objects must implement the IObjectControl interface. Delphi does this for us in the TMtsAutoObject. When a COM+ object is deactivated, COM+ calls the CanBePooled method on the IObjectControl interface. If this method returns true, the object is added to the object pool, otherwise it is destroyed. To make sure that this method returns true for out COM+ object, we need to set the Pooled property to True. A good place to do this is in the Initialize method, which we can easily override :

procedure TMyCOMPlusObject.Initialize;
  Pooled := True;

Turn on object pooling on the CoClass

Finally, the CoClass for our COM+ object has a setting on the COM+ tab in the Type Library Editor in which you can supposedly enable/disable object pooling and set the default time (in milliseconds) that an object will stay in the pool before being free. These settings seem to have no effect in my tests, but the Delphi Help says they must be checked.

How big is your pool?

Enabling pooling for Delphi COM+ objects is the easy part. Configuring the pool is somewhat more challenging. Why? Well, if you get it wrong, it could cause a serious performance degradation in your application.

The maximum pool size is the critical setting. New objects will be created if there are none available in the pool until the number of objects created equals the maximum pool setting. After this, requests for objects are queued. If no object becomes available within the creation timeout then the request will return with an error. Your client application should have error-handling to deal with this possibility.

The minimum pool size determines the minimum number of objects in the pool at any time. Objects will automatically be created when the application starts -- this setting is useful for preallocation of objects so they are immediately available to clients. Note that setting this to a high number can have performance implications, due to the amount of memory being allocated when the application starts up.

Changes to these settings do not take effect until the application has been restarted.

Stats 'n' stuff

Of course you would hope that by simply turning on object pooling, you will instantly see a performance improvement in your application. Often this will be difficult to quantify. (Did that page load faster than before? Maybe) The difference may be that the application scales somewhat better, or the application may actually perform worse than it did before. COM+ provides some stats that you can easily access which might give some idea of what's happening.

Enabling object statistics

In the details pane of the Component Services administrative tool, right-click the component that you want to configure, then click Properties. In the component properties dialog box, click the Activation tab. To enable object statistics for the component, select the Component supports events and statistics check box.

Monitoring object status

In the console tree of the Component Services administrative tool, open the folder for the application that includes the components you want to monitor. Right-click the Components folder, point to View, then click Status View. The details pane now displays the status view for all components in the application.

The table below describes the columns in the Status View :

Column Description
ProgID Identifies a specific component.
Objects Shows the number of objects that are currently held by client references.
Activated Shows the number of objects that are currently activated.
Pooled Shows the total number of objects created by the pool, including objects that are in use and objects that are deactivated.
In Call Identifies objects in call.
Call Time (ms) Shows the average call duration (in milliseconds) of method calls made in the last 20 seconds (up to 20 calls). Call time is measured at the object and does not include the time used to traverse the network.

The moment of truth

The best way to determine what (if anything) may be gained by using object pooling is to do proper performance testing with and without object pooling enabled. Then perform experiments with the minimum and maximum pool sizes to get the best out of your hardware. Monitor the memory and CPU usage of your server. The settings you eventually end up with will be a tradeoff between memory usage and CPU load.

While researching this article, I was hoping to find some document somewhere that would provide some hard and fast rules for configuring COM+ and object pooling. But I've had no luck so far.

Vincent lives and works in Canberra, Australia, where he specializes (well, he's from Australia, so he specialises) in developing components, developer tools and web applications using Delphi. He can be reached at and at

Server Response from: ETNASC03