Сеанс ASP.NET и хранение объектов, использующих взаимодействие COM

Question

Я работаю над сайтом asp.net. Мы должны использовать com interop для взаимодействия с устаревшими компонентами vx6 activex. Во многих случаях компоненты полагаются на получение объекта контекста (который сам является компонентом vx6 activex) в качестве параметра. Создание объекта контекста довольно затратно.

Поэтому одна идея состоит в том, что объект контекста создается один раз и сохраняется в сеансе asp.net. Однако, если этот объект является просто оболочкой .net вокруг компонента activex, целесообразно или целесообразно сохранить такой объект в сеансе?

Кроме того, объект контекста содержит информацию, специфичную для пользователя, поэтому можно использовать постоянное использование .net HttpRuntime Caching, но для этого потребуется ключ, специфичный для пользователя.

Я понимаю другие ограничения и вещи, о которых вам необходимо знать в сеансе asp.net, вопрос aspnet-сессии .

Чтобы задать вопрос немного по-другому: есть ли у них какие-либо проблемы или проблемы с хранением объекта .net, который является просто оболочкой вокруг com-объекта?

Answer 1

Я думаю, вы очень быстро получите проблемы с одним запросом, блокирующим другой.

ASP.NET по умолчанию инициализирует COM в своих потоках, чтобы поместить поток в многопоточную квартиру. Компоненты VB6 были в лучшем случае моделью квартиры. Это означает, что когда поток MTA создает компонент, он помещается в основную STA, если он уже существует (чего не будет для рабочих процессов ASP.NET), или новый поток создается специально для STA. Не имеет значения, какой поток MTA создает компонент, всегда используется одна и та же STA для компонентов, которые не могут обрабатывать модель MTA. Это означает, что один и тот же поток используется для каждого вызова этих компонентов, поэтому одновременные вызовы должны ждать в очереди.

Чтобы ASP.NET инициализировал COM для однопоточных компонентов, что по крайней мере приведет к созданию объекта в том же потоке, что и выполняющаяся страница, добавьте атрибут AspCompat в @ Page директива.

Я бы не стал кэшировать объекты, так как при повторном их использовании очень вероятно возникновение межпоточных проблем.

Answer 2

Я бы сохранил его в кеше, чтобы он не создавался один раз для пользователя, если только это не желаемый эффект.