ASP、Server.CreateObject、MTS 和 C# 对象池——重用问题？
我正在尝试调试一个“偶尔”的问题。 我们有一个经典的 ASP 应用程序需要发送电子邮件。 不管出于什么原因，它使用通过 COM 公开的 C# 对象来执行此发送； C# 对象是 MailMessage 和 SMTPClient 的简单包装，使用 SendAsync 进行发送。 在 ASP 端，在发送每封邮件之前都会对对象进行 Server.CreateObject() 处理，但邮件消息是在紧密循环中发送的。 这应该为每条消息生成一个新的 COM 对象（因此也是一个新的 C# 对象）。 但是，我们看到消息被丢弃，消息被发送给多个收件人，就好像该对象被重用一样。
经过对 MTS 的一些研究（从来没有想过我会再去那里！）我记得/发现 Server.CreateObject 通过 MTS 并且 MTS 将池 COM 对象以“帮助”我。 我们更改了 ASP 代码以执行新的 ActiveXObject，我认为这没有经过 MTS，但我们遇到了同样的问题。
我是否正确假设 .net 中的 ServicedComponent 接口是 ObjectControl 接口的 .net/com+ 版本？ 如果我从 ServicedComponent 继承，该对象是否会被设置为允许 pooling = false？ 我宁愿在 ASP 中进行更改，但如果不可能，那么我也可以对 C# 进行更改。
想法？
编辑：页面语言也是 JScript，而不是“普通”VBScript。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这种情况下，Server.CreateObject 和新的 ActiveXObject 将全部执行相同的操作。
COM+ 不会对未明确指示可以进行池化的对象进行池化。
我想做的是调查这里使用 .NET 组件的原因是什么，为什么不使用 CDO.Message？ SendAsync 的使用尤其令人困惑。 如果您的循环很紧，只是发送电子邮件，那么 SendAsync 对您来说作用不大。
我想不出在这种情况下避免使用 CDO.Message 的充分理由，但这当然可能是因为我们缺少其他因素。
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.