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
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,
not destroy the object, but will return it to the object pool so it can be
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:
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 :
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
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 :
||Identifies a specific component.
||Shows the number of objects that are currently held by client references.
||Shows the number of objects that are currently activated.
||Shows the total number of objects created by the pool, including objects that are in use and
objects that are deactivated.
||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 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
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
firstname.lastname@example.org and at