Question

I’m working on an asp.net web site. We have to use com interop to interact with legacy vb6 activex components. The components in many cases rely on receiving a context object (which is itself a vb6 activex component) as a parameter. The context object is fairly costly to construct.

Therefore one idea is that a context object is constructed once and stored in asp.net session. However, if this object is just a .net wrapper around an activex component, is it wise or advisible to persist such an object in session?

Additionally the context object contains user specific information, so persisting using .net HttpRuntime Caching could be used, but would require a user specific key.

I understand the other limitations and things you need to be aware of with asp.net session, aspnet-session question.

To ask the question a slightly different way: are their any issues or problems with storing an .net object that is just a wrapper around a com object?

Answer 1

I think you will very rapidly get problems with one request blocking another.

ASP.NET by default initialises COM on its threads to put the thread in a multi-threaded apartment. VB6 components were apartment-model at best. That means that when the MTA thread creates the component, it’s put into the main STA if one already exists (which for ASP.NET worker processes, it won’t) or a new thread is created specifically for the STA. It doesn’t matter which MTA thread creates the component, the same STA is always used for the components that can’t handle the MTA model. That means the same thread is used for every call to those components, so concurrent calls have to wait in line.

To tell ASP.NET to initialize COM for single-threaded components, which will at least cause the object to be created on the same thread as the executing page, add the AspCompat attribute to the @Page directive.

I would not cache the objects as they’re very likely to have cross-thread issues when they’re reused.