ASP, Server.CreateObject, MTS and C# object pooling -- a reuse problem?

Question

I'm trying to debug an "occasional" problem. We've got a classic ASP application that needs to send email. For whatever reasons it's using a C# object exposed via COM to do this send; the c# object is a simple wrapper around MailMessage and SMTPClient, using SendAsync to do the send. On the ASP side the object is Server.CreateObject()'d before each mail is sent, but mail messages are sent in a tight loop. This should result in a new COM object (and therefore a new c# object) for each message. However, we're seeing messages dropped and messages sent to multiple recipients as if the object is being reused.

After some research into MTS (never thought I'd go there again!) I've remembered/discovered that Server.CreateObject goes through MTS and MTS will pool COM objects in order to "help" me. We've changed the ASP code to do a new ActiveXObject instead, which I thought didn't go through MTS, but we have the same problem.

Am I correct in assuming that the ServicedComponent interface in .net is the .net/com+ version of ObjectControl interface? If I inherit from ServicedComponent will the object then be set to allow pooling = false? I'd rather make the change in the ASP, but if that's not possible, then I can make the c# change too.

Thoughts?

Edit: The page language is JScript too, not the "normal" VBScript.

Answer 1

Server.CreateObject and new ActiveXObject will all to the same thing in this case.

COM+ won't pool an object that doesn't explictly indicate that it can be pooled.

What I'd be inclined to do is to investigate what the reasons are for using a .NET component here, why is CDO.Message not being used? Use of SendAsync is especially confusing. If you have a tight loop just sending emails then SendAsync does very little for you.

I can't think a good reason to avoid using CDO.Message in this case but of course that could be because we're missing other factors.