Sorry, forgot to mention that yes, tried the MTA option on the threading
model at the beginning since this is so easy to try. Didn't change anything-
next thing to try was the spawn new thread, start it (run long-running com
call in it) then join it, which wasn't very hard. Next thing to try was the
async http interface and async page class which was a pain, and still didn't
work.
aspcompat makes no sense for this COM object, which is a C++ multithreaded
object.
The problem starts "at the top" when the aspx.cs code is run as a CLR
"thread" instead of a win32 true system thread. Because the CLR is operating
in this separate multitasking model, it is apparently incapable of task
switching if it is inside a COM/unmanaged function.
I suppose you could posit that the threading model in ASP.NET is "superior"
to ASP for homogeneous short-lived ASPX pages in environments with very large
numbers of users. However, for environments with some legacy requirements
(including COM components that are non-trivial to convert to managed), the
"self-contained" threading model in the CLR has a very poor performance
profile for environments with, simply, "more than one" concurrent user. If
you only have a hundred or so active users, concurrent requests probably
won't run over 20 or so. I honestly in all my years of low-to-high level
systems coding have never seen any issue with win32 being able to
context-switch 20 system threads, even hundreds which is actually what it is
doing in the OPSYS anyway!
I am a big .NET and ASP.NET fan and have bet a huge amount of tools
development effort on it, but it doesn't mean I have to love every aspect
unconditionally. I would love to be corrected and provided a real solution
to my problem: the context switching in the CLR engine is simply not
compatible with COM objects, STA or MTA.
In a COM call = no CLR context switch
No context switch = no multitasking
No multitasking = step backwards
If there is a directive I can put in my ASPX page that requests a 1-1 CLR
thread to system thread...hooray. Anyone know of one? Sure sounds like a
good idea for those of us that need it.
Otherwise, I have to schedule-in an immediate upgrade of the COM component
to a mixed managed/unmanaged code implementation and have concerns about how
far into the codebase I will have to go to enable a context switch when
inside the ASP.NET CLR environment.
"David Browne" wrote:
"Bill Thorne" <Bi********@discussions.microsoft.com> wrote in message
news:EC**********************************@microsof t.com... We have a COM object that has been wrappered for use in .NET and which can
make calls which can take a while to execute. These are mainframe
integration calls that might perform a lot of data entry and gathering,
returning the results to the ASP.NET caller.
. . . The multithreading in ASP.NET is poor. Long
running pages shouldn't hold-up short running pages.
No they don't. Threading in .NET is far superior to COM. What you are
seeing is probably a result of not setting the apartment model of your
threads correctly to work with your fusty old COM component.
What is the threading model of the COM component?
Did you set AspCompat='True' on the ASPX page?
David