Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Accessing DCOM components from the code behind pages and using sessions to store DCOM object handles

Reply
Thread Tools

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

 
 
Alex
Guest
Posts: n/a
 
      12-01-2003
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?


 
Reply With Quote
 
 
 
 
bruce barker
Guest
Posts: n/a
 
      12-02-2003
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" <(E-Mail Removed)> wrote in message
news:bqgkd2$sp9$(E-Mail Removed)...
> 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?
>
>



 
Reply With Quote
 
 
 
 
Alex
Guest
Posts: n/a
 
      12-02-2003
How about my free threaded component?
Do I need to switch it to apartement threaded?

"bruce barker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:bqgkd2$sp9$(E-Mail Removed)...
> > 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?
> >
> >

>
>



 
Reply With Quote
 
Alvin Bruney
Guest
Posts: n/a
 
      12-02-2003
> 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" <(E-Mail Removed)> wrote in message
news:bqgkd2$sp9$(E-Mail Removed)...
> 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?
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question about file handles and windows handles @ Windows Operating Systems eino Python 1 05-08-2007 09:14 PM
Accessing components on other pages CJ ASP .Net 3 12-09-2005 03:20 PM
Using User Controls, Code-Behind, Components and ASPX files Ric ASP .Net 2 11-30-2004 01:29 PM
Re: Accessing UserControls in ASPX code-behind pages Mark Fitzpatrick ASP .Net 2 04-24-2004 05:16 PM
Re: Code Behind vs. no code behind: error Ben Miller [msft] ASP .Net 1 06-28-2003 01:46 AM



Advertisments