Объединение объектов ASP, Server.CreateObject, MTS и C # - проблема повторного использования? - PullRequest
2 голосов
/ 13 мая 2009

Я пытаюсь отладить "случайную" проблему. У нас есть классическое приложение ASP, которое должно отправлять электронную почту. По тем или иным причинам он использует объект C #, предоставляемый через COM, для выполнения этой отправки; объект c # - это простая оболочка для MailMessage и SMTPClient, использующая SendAsync для отправки. На стороне ASP объект Server.CreateObject () 'перед каждой отправкой почты, но почтовые сообщения отправляются в тесном цикле. Это должно привести к созданию нового COM-объекта (и, следовательно, нового объекта c #) для каждого сообщения. Однако мы видим, что сообщения отбрасываются и сообщения отправляются нескольким получателям, как будто объект используется повторно.

После некоторого исследования MTS (никогда не думал, что пойду туда снова!) Я вспомнил / обнаружил, что Server.CreateObject проходит через MTS и MTS будет объединять COM-объекты, чтобы «помочь» мне. Мы изменили код ASP, чтобы вместо него создать новый ActiveXObject, который, как я думал, не прошел через MTS, но у нас та же проблема.

Правильно ли я полагаю, что интерфейс ServicedComponent в .net является версией .net / com + интерфейса ObjectControl? Если я унаследую от ServicedComponent, будет ли объект разрешен пул = false? Я бы предпочел внести изменения в ASP, но если это невозможно, то я тоже могу внести изменения в c #.

Мысли

Редактировать: язык страницы тоже JScript, а не "нормальный" VBScript.

1 Ответ

1 голос
/ 15 мая 2009

Server.CreateObject и новый ActiveXObject в этом случае будут совпадать.

COM + не будет объединять объект, который явно не указывает, что его можно объединить в пул.

Что бы я хотел сделать, это выяснить причины использования здесь компонента .NET, почему CDO.Message не используется? Использование SendAsync особенно запутанно. Если у вас есть тесная петля, просто отправляющая электронную почту, то SendAsync мало что сделает для вас.

Я не могу представить себе вескую причину избегать использования CDO.Message в этом случае, но, конечно, это может быть потому, что мы упускаем другие факторы.

...