Accessing DCOM components from the code behind pages and using sessions to store DCOM object handles

[Alex]

I'm having a problem porting an ASP solution to ASPX.
In the ASP solution I'm accessing a DCOM server, create sub DCOM objects and
call functions from VB script on the ASP pages.
The DCOM object handles are stored in session variables.
This works fine without a problem.

Ported it to ASPX, accessing the same DCOM server from code behind pages.
Still, usually no problems.
However sometimes I'm seeing an error stating that the DCOM handle used
(stored in a session variable) used is not valid in this thread.
It looks like that the ASPX engine has a different model to use threads than
the ASP engine.

Does anyone know how to solve this? How do I restrict the threading? Or how
can I pass DCOM handles (pointers) around in this new environment without
running into this problem?
How does ASP do the threading differently?

[bruce barker]

aspx is thread agile and is designed to call free-threaded objects. if you
call any apartment model objects (vb6), you need to set aspcompat=true on
every that call on. this has a performance hit, as it restricts threading.

-- bruce (sqlwork.com)
"Alex" <so*****@nospam.com> wrote in message
news:bq**********@news.mch.sbs.de...

I'm having a problem porting an ASP solution to ASPX.
In the ASP solution I'm accessing a DCOM server, create sub DCOM objects and call functions from VB script on the ASP pages.
The DCOM object handles are stored in session variables.
This works fine without a problem.

Ported it to ASPX, accessing the same DCOM server from code behind pages.
Still, usually no problems.
However sometimes I'm seeing an error stating that the DCOM handle used
(stored in a session variable) used is not valid in this thread.
It looks like that the ASPX engine has a different model to use threads than the ASP engine.

Does anyone know how to solve this? How do I restrict the threading? Or how can I pass DCOM handles (pointers) around in this new environment without
running into this problem?
How does ASP do the threading differently?

[Alex]

How about my free threaded component?
Do I need to switch it to apartement threaded?

"bruce barker" <no***********@safeco.com> wrote in message
news:uW**************@TK2MSFTNGP09.phx.gbl...

aspx is thread agile and is designed to call free-threaded objects. if you
call any apartment model objects (vb6), you need to set aspcompat=true on
every that call on. this has a performance hit, as it restricts threading.

-- bruce (sqlwork.com)
"Alex" <so*****@nospam.com> wrote in message
news:bq**********@news.mch.sbs.de...

I'm having a problem porting an ASP solution to ASPX.
In the ASP solution I'm accessing a DCOM server, create sub DCOM objects

and

call functions from VB script on the ASP pages.
The DCOM object handles are stored in session variables.
This works fine without a problem.

Ported it to ASPX, accessing the same DCOM server from code behind pages. Still, usually no problems.
However sometimes I'm seeing an error stating that the DCOM handle used
(stored in a session variable) used is not valid in this thread.
It looks like that the ASPX engine has a different model to use threads

than

the ASP engine.

Does anyone know how to solve this? How do I restrict the threading? Or

how

can I pass DCOM handles (pointers) around in this new environment without running into this problem?
How does ASP do the threading differently?

[Alvin Bruney]

> The DCOM object handles are stored in session variables.

This works fine without a problem. Very very very bad. Did I mention this was bad?

There are a lot of issues that are stinging you. Asp.Net runs in the MTA.
The web page or more specifically, the hosting container, which is IE runs
in the STA. If you are manipulating anything with COM, you should make sure
that you set aspcompat = true on the page to force threads to be run in the
same apartment in which they were created. The MTA executes on any thread
from a pool of given threads so you are going to suffer at least performance
degradation and at most deadlocks when thread context switching occurs.

In addition, you absolutely do not want to store handles to unmanaged
resources in serialized containers like session objects. This is bad for
several reasons, one of which is that COM gets seriously confused when
trying to determine if the object still has references attached to it (keep
alive pinging) resulting in hung processes, deadlocks, leaks etc.

The best approach I can think of for storing unmanaged pointers is to wrap
the COM object in a class and provide dispose methods to obtain and release
the object. Your accessor methods will know how to return a pointer
correctly and cleanly. There are other approaches but this is the one which
sticks out at the moment.

--
Regards,
Alvin Bruney
Got Tidbits? Get it here
www.networkip.net/tidbits
"Alex" <so*****@nospam.com> wrote in message
news:bq**********@news.mch.sbs.de... I'm having a problem porting an ASP solution to ASPX.
In the ASP solution I'm accessing a DCOM server, create sub DCOM objects and call functions from VB script on the ASP pages.
The DCOM object handles are stored in session variables.
This works fine without a problem.

Ported it to ASPX, accessing the same DCOM server from code behind pages.
Still, usually no problems.
However sometimes I'm seeing an error stating that the DCOM handle used
(stored in a session variable) used is not valid in this thread.
It looks like that the ASPX engine has a different model to use threads than the ASP engine.

Does anyone know how to solve this? How do I restrict the threading? Or how can I pass DCOM handles (pointers) around in this new environment without
running into this problem?
How does ASP do the threading differently?