468,283 Members | 1,938 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,283 developers. It's quick & easy.

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

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?
Nov 18 '05 #1
3 1769
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?

Nov 18 '05 #2
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?


Nov 18 '05 #3
> 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?

Nov 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Mike Carter | last post: by
8 posts views Thread by Paul van't Klooster | last post: by
1 post views Thread by Gabby Shainer | last post: by
3 posts views Thread by Oleg Skopincevs | last post: by
13 posts views Thread by Kyle Adams | last post: by
reply views Thread by zattat | last post: by
2 posts views Thread by MrBee | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.