How is Object Pooling Implemented in COM+?
Behind this Concept...
THIS ARTICLE DISCUSSES THE CONCEPT BEHIND THE IMPLEMENTATION OF OBJECT POOLING IN COM+ RUNTIME.
What is COM?
It's a technology that defines a standard way for a client module and server module to communicate through a set of interfaces. The module could be an application or a DLL. Also the client and server can be in the same box or in different boxes
What is COM+?
It's just an extended version of COM coming with Windows 2000. Microsoft has redefined and added some concepts/features with COM+.
What is Object Pooling and Why do we need Object Pooling?
To better illustrate the need for Object Pooling, let us consider a sample web application using COM objects. The basic functions of such an application using a COM object would be the following:
a. Creates a COM object
b. Uses the COM object by calling various methods/properties.
c. Destroys the COM object
Let us assume that we have an ASP page in that web application and got some 30,000 requests for a day/at peak times. Let us suppose that the ASP page creates three COM objects in that page. So as per the calculation, there would be 90,000 objects created and destroyed. No need to say, it will definitely consume a lot of resources and an overhead. What could be done to avoid this? Recycle. Yes. We can recycle the objects used at one transaction in the next transaction.
Here comes the Object Pool. It's a place where the application return the COM objects after using it instead of destroying it. So every time the application needs a COM object, it needs to perform the following steps:
a. Checks the object pool if one exists. If exists, then use it or creates a new COM object.
b. Use the COM object by calling its methods/properties.
c. Return it to the same object pool after using it.
This looks like a good concept in reducing/conserving the usage of resources in a web application. But the next question comes to our mind is that can we implement all of those in an web application? We can; but we need to think of the following things in mind.
a. Who is responsible for managing the Object Pool?
b. When that Object Pool will be created/destroyed?
c. When will the objects be created/destroyed in that pool?
d. When those objects will be destroyed in that pool?
e. How will the web application know to use the objects in the pool? Does the application need to write a separate code to call an object in the object pool?
f. How can we manage multiple clients accessing an object in the object pool?
But implementing these in every web application is really a difficult task and it's an overhead on the programmer's side; Also it's error prone.
Here comes the COM+!!!
COM+ helps us in doing all those processes without changing a single line of code in our COM object. That's the beauty of COM+. A COM+ application is typically an MTS application in the earlier Windows versions(NT,95); but in Windows 2000, the name has been changed to COM+. That's it.
COM+ provides us with a lot of services. One of its services is this Object Pooling. All we have to do is to set the component properties in Component Services Editor to use Object Pooling. The rest will be taken care of by the COM+ runtime.
But in COM+ 1.0, there are some restrictions on using its services by COM objects developed by various languages. This is because of the incompatibility between the COM+ and the languages.
As of now, COM objects developed using Visual Basic cannot use this Object Pooling service provided by the COM+. Is that right? Any ideas? What about COM objects developed using Delphi? Is Delphi 5.0/6.0 COM+ compatible? Can Delphi 5.0/6.0 use all of the services provided by COM+? Because, I didn't get a chance to try these out. Discussions are welcome!!!
When COM Objects are destroyed?
As every COM programmer knows, COM implements some basic methods.
Out of these methods, Release is responsible for destroying the object. After the COM Object is created, every time a method of the COM Object is called, it'll call AddRef method to increase the reference count for that component. And after the method call has been over, the reference count will be reduced by one and once it reaches zero, the COM object will be destroyed.
Reference count is a number that indicates the number of active clients using the COM object.
How Object Pooling is implemented in COM+?
This is implemented by intercepting the calls to the Release method of IUnknown. As you know already, every COM object maintains a reference count and once it reaches zero, then that COM object is destroyed. But this is not good if we would like to reuse/recycle the object. In turn, it's not good to implement the Object Pooling service. So the following are implemented by COM+:
a. COM+ maintains an additional reference count for COM objects to be pooled when the object is created.
b. COM+ intercepts the calls to Release method for pooled COM objects.
The above two things are implemented by a technique called Interception. The interception is implemented by a light-weight proxy. It's also called an Interceptor. It contains a small amount of code that acts between the client and the real object. This code is invoked for components which are marked as pooled components. So by this technique, inteception, COM+ runtime implements the Object Pooling.
All these are happening behind the scenes by COM+ runtime. All we have to do to make use of this Object Pooling service is to make sure that we set the right 2option in the Component Services Editor. Component Services is available in Win 2000.
This article is just a beginning to COM+ and I would like to explore more on this COM+ later. If you have any views,comments or have any experience with that, please feel free to share.