On the Mark: 9/4/2002

	Wednesday, September 04, 2002

Microsoft's terms for COM+ instance management algorithms are very confusing. Object Pooling means more or less what you might think - a pool of object instances that can be connected to an incoming request at need. Instance Pool would be a better term, but I can let this slide. In Microsoft's parlance, a COM+ managed object is either pooled or it is not. This is crucial to understand. This makes it clearer that Just In Time Activation is not a mutually exclusive condition - even thought it sounds like it is. JITA actually refers to lazy binding of the client-side proxy to a stub - but has nothing to do with the actual binding to an instance. Thus a developer can try the following combinations:

JITA alone: this results in a Just In Time Instantiation policy whereby the object is created on method invocation and then thrown away when the method completes. This is a good approach if instance initialization takes a minimum amount of time.
JITA and Object Pooling: this results in a pool of object instances, one of which is connected at the point of method invocation. Technically these are returned to the pool afterward. In reality, I think the client has to invoke the DisposeObject() method before the instance is returned to the pool. This is good when initialization of the object takes a while (e.g. grabbing a database connection).
Object Pooling alone: this results in a pool of objects also. However, the client is connected when they create the object instance (proxy). That connection is retained through method invocation until DisposeObject() is called. This is not generally advisable since it is not very scalable.
Neither JITA nor Object Pooling: this is standard COM fare. It is also the default! This does not stand a chance of scaling because every client is connected to their own individual, non-shared object instance. The connection is retained until the object reference count goes to 0.

Do not stick with the default if you are building a web app!
2:33:12 PM

Google It!

I did a little research on connection pooling. Here are some interesting, if inconclusive, excerpts from the MSDN Library.

Connection pooling is available in the following ways.

Microsoft Transaction Server (MTS) provides object pooling.
ODBC 3.0 has a connection pooling feature that is enabled by default in Active Server Pages (ASP).
... As a general guideline, you should create data source connections using the ActiveX Data Objects (ADO) Connection object and use MTS to pool and recycle the connection.

So, it looks like ODBC does provide connection pooling. It is somehow enabled by ASP. If you are writing MTS (and, I assume, COM+) apps you should use object pooling to get the same effect.

Ah, here is an MSDN article with more detailed info on ODBC connection pooling. Excerpts...

To take advantage of connection pooling, a driver must be thread-safe.
The behavior of ODBC connection pooling can be programmatically controlled by an ODBC-based application (ed. if you use the native ODBC API).
At the Data Source Administrator level, pooling can be enabled or disabled for the entire driver.

On my Windows 2000 machine I could not find anything under the "Connection Pooling" tab that allowed me to control connection pooling by driver. I could only enable/disable performance monitoring of the connection and set the Retry Wait Time. Digging further into the previous article, I did find that you can also control connection pooling, on a per driver basis, through the registry. For example, the key HKEY_LOCAL_MACHINESOFTWAREODBCODBCINST.INISQL Server contains a value of CPTimeout that controls how long the connection should be kept in a pool until it is released (closed). Setting the value to zero disables connection pooling.

Oh, so that's how you do it! I found that by double-clicking the driver name in the Connection Pooling dialog of the ODBC Administrator) another dialog pops up that allows you to configure pooling parameters. Unintuitive, but it does work.
12:46:33 PM Google It!

My friend George and I have a minor disagreement on where database connection pooling is performed in the .NET/ODBC/COM+ world and in the WebSphere/JDBC world. I believe I read in Roger Sessions book COM+ and the Battle for the Middle Tier that ODBC does the connection pooling, not COM+ (or even ADO). I believe he also states that JDBC handles its own connection pooling rather than WebSphere.

I do not know WebSphere/JDBC any where near well enough to prove or disprove this assertion. However, I should be able to design an experiment to determine the truth on the .NET/COM+ platform. I wonder how I should go about this?
12:06:17 PM

I am writing this one day just in case I ever need it. If I happen to write a .NET server application - an .exe not intended to run under the auspices of a COM+ provided container - it must be registered in the Global Assembly Cache using the gacutil tool. OK, I am pretty sure I will not be writing one of these; I will stick to small components packaged as dlls. Keywords: gacutil, application server, stupid things I forget, .NET, COM+.
11:56:15 AM

Using regsvcs.exe I am now able to quickly change my .NET component from library activation to server activation. Of course, it would be quicker still to simply using the Microsoft Management Console to change the application's properties. Doing it that way would not affect any code. I wonder what happens if I describe the application within the component as being library activated, but configure the app itself, through MMC, as something different. I bet the last definition wins, but let us be certain.

I am using a very simple component as the basis for my testing. It supports a method that returns the process id under which it is running. The client prints both the process id for the component and for itself. If they are the same, then the component is obviously library activated - running in the same process as the client. If the two are different, then the component is application activated.

The component is currently marked for application activation. I am now reconfiguring the app itself, through MMC, to perform library configuration. On running the test the Process IDs are identical, so it appears that the ApplicationActivation attributes in the component are a convenience item only for dynamic registration. They can be overridden within MMC. I suppose this is true of all other properties as well: synchronization, JIT activation, transaction support, etc.
11:52:33 AM

I have been playing around with using COM+ services in .NET and have learned some hard lessons. First, while .NET does a really nice job of automatically registering a .NET implemented COM+ component, it does so only the first time the component is created. You have to do it manually thereafter. Since it is likely during development that you will frequently change the component, you will have to resort to manual registration. It turns out this is relatively painless and provides better feedback on errors to boot.

Even after learning this I had trouble with the manual registration. It turns out that an early development attempt had resulted in a registration I was unaware of under an application name I was unaware of. I found that uninstalling that application (regsvcs /u appname dllName) solved that problem. Then I was able to successfully register the component (regsvcs dllName). From then on I re-registered with every change to the dll (regsvcs /reconfig dllName). See the .NET Framework SDK Documentation for more info.
11:39:16 AM