Home All Groups Group Topic Archive Search About
Author
10 Jun 2005 5:01 AM
Venkat
Hi,
     We have a dozens of VB6 components, developed some 5 years before, we
have now  few .Net components which references these files. Ideally we are
using Biztalk server and referencing these VB6 components into that, what
happens is that during actual transaction with several instances, the
process(biztalk)
gets automatically shutdown.

on researching the problem it was found that all VB6 compentes were STA and
so when loaded into memory it caused a deadlock problem. The solun ideally is
to convert all the vb6 componets to .net components, but as of now this is
practically impossible.

can any one suggests an alternate method so that the process goes with MTA
instead of STA or atleast any ways to minimise the deadlock condition?

Author
10 Jun 2005 8:35 AM
Willy Denoyette [MVP]
Show quote Hide quote
"Venkat" <Ven***@discussions.microsoft.com> wrote in message
news:71D078A4-EBFE-4A92-A585-915F239D62BD@microsoft.com...
> Hi,
>     We have a dozens of VB6 components, developed some 5 years before, we
> have now  few .Net components which references these files. Ideally we are
> using Biztalk server and referencing these VB6 components into that, what
> happens is that during actual transaction with several instances, the
> process(biztalk)
> gets automatically shutdown.
>
> on researching the problem it was found that all VB6 compentes were STA
> and
> so when loaded into memory it caused a deadlock problem. The solun ideally
> is
> to convert all the vb6 componets to .net components, but as of now this is
> practically impossible.
>
> can any one suggests an alternate method so that the process goes with MTA
> instead of STA or atleast any ways to minimise the deadlock condition?

Simple solution is to create/access instances of those COM objects on/from a
STA threads, that is initialize your threads as STA by setting the
ApartmentState to STA before starting the thread.

Willy.
Are all your drivers up to date? click for free checkup

Author
10 Jun 2005 8:46 AM
stic
Hi Willy,

Maybe as a MVP you would know this...
Do you know why the pages at MSDN which discribes STA and MTA are
disappiring ?

--
best regards
stic
Author
10 Jun 2005 9:34 AM
Willy Denoyette [MVP]
"stic" <stefan.tural***@gmail.com> wrote in message
news:1118393188.768408.122490@o13g2000cwo.googlegroups.com...
> Hi Willy,
>
> Maybe as a MVP you would know this...
> Do you know why the pages at MSDN which discribes STA and MTA are
> disappiring ?
>
> --
> best regards
> stic
>

I'm not clear on what you mean with "disappiring", but if you mean there is
no info about STA/MTA on msdn, you could do a search for "single threaded
apartment" on msdn and you will get a huge list of hits.
One of them is:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/cb62412a-d079-40f9-89dc-cce0bf3889af.asp
Or are you looking for something else?

Willy.
Author
10 Jun 2005 8:57 AM
Venkat
I didnot understand, can you be more specific with an example?

venkat.

Show quoteHide quote
"Willy Denoyette [MVP]" wrote:

>
> "Venkat" <Ven***@discussions.microsoft.com> wrote in message
> news:71D078A4-EBFE-4A92-A585-915F239D62BD@microsoft.com...
> > Hi,
> >     We have a dozens of VB6 components, developed some 5 years before, we
> > have now  few .Net components which references these files. Ideally we are
> > using Biztalk server and referencing these VB6 components into that, what
> > happens is that during actual transaction with several instances, the
> > process(biztalk)
> > gets automatically shutdown.
> >
> > on researching the problem it was found that all VB6 compentes were STA
> > and
> > so when loaded into memory it caused a deadlock problem. The solun ideally
> > is
> > to convert all the vb6 componets to .net components, but as of now this is
> > practically impossible.
> >
> > can any one suggests an alternate method so that the process goes with MTA
> > instead of STA or atleast any ways to minimise the deadlock condition?
>
> Simple solution is to create/access instances of those COM objects on/from a
> STA threads, that is initialize your threads as STA by setting the
> ApartmentState to STA before starting the thread.
>
> Willy.
>
>
>
Author
10 Jun 2005 10:02 AM
Willy Denoyette [MVP]
Just to make sure we are talking about managed code here.
Your VB6 COM objects are created and accessed from from C# (.NET) managed
code right?

Willy.

Show quoteHide quote
"Venkat" <Ven***@discussions.microsoft.com> wrote in message
news:D49BD631-6C53-412F-8CBA-805FB8E801BB@microsoft.com...
>I didnot understand, can you be more specific with an example?
>
> venkat.
>
> "Willy Denoyette [MVP]" wrote:
>
>>
>> "Venkat" <Ven***@discussions.microsoft.com> wrote in message
>> news:71D078A4-EBFE-4A92-A585-915F239D62BD@microsoft.com...
>> > Hi,
>> >     We have a dozens of VB6 components, developed some 5 years before,
>> > we
>> > have now  few .Net components which references these files. Ideally we
>> > are
>> > using Biztalk server and referencing these VB6 components into that,
>> > what
>> > happens is that during actual transaction with several instances, the
>> > process(biztalk)
>> > gets automatically shutdown.
>> >
>> > on researching the problem it was found that all VB6 compentes were STA
>> > and
>> > so when loaded into memory it caused a deadlock problem. The solun
>> > ideally
>> > is
>> > to convert all the vb6 componets to .net components, but as of now this
>> > is
>> > practically impossible.
>> >
>> > can any one suggests an alternate method so that the process goes with
>> > MTA
>> > instead of STA or atleast any ways to minimise the deadlock condition?
>>
>> Simple solution is to create/access instances of those COM objects
>> on/from a
>> STA threads, that is initialize your threads as STA by setting the
>> ApartmentState to STA before starting the thread.
>>
>> Willy.
>>
>>
>>
Author
11 Jun 2005 8:26 AM
Richard Blewett [DevelopMentor]
The issue is that these methods are executing under BizTalk 2004. This means that the VB6 components are being called from ThreadPool threads which will enter the MTA and so all the VB6 components will join the Host STA (all of them will be serviced on the same thread) which is not good for scaleability.

One solution would be to write a .NET component that managed a custom thread pool of STA threads and ran a number of VB6 objects in those STAs. However, this is a non-trivial thing to build (and to some degree is a bit like reimplementing part of MTS ;-) ) - which thinking about it could be another solution - to host the VB6 components under COM+ and use COM+s threading infrastructure to provide the multiplexing.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

   Just to make sure we are talking about managed code here.
Your VB6 COM objects are created and accessed from from C# (.NET) managed
code right?

Willy.
Author
11 Jun 2005 9:55 AM
Willy Denoyette [MVP]
Richard,

I didn't look into Biztalk 2004 yet, but as it looks like it's not that "COM
friendly" environment to live in.
All STA (that is all VB6) objects will be hosted by the SINGLE STA host
thread so all calls have to be serialized/marshaled which is not scalable at
all, worse, who guarantees correct message pumping on this thread (which
might explain the deadlock issues OP is referring to)? When one such
component fails it brings down the whole process.
So I'm in full agreement with you as to host these STA objects in a server
type COM+ application or multiple applications, which is IMO the environment
where most such "server" style components should live. Sure you pay the
inter-process call overhead, but you get a lot back like multiple threads
hosting STA's, security process control ...

Willy.


Show quoteHide quote
"Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in
message news:uuaCX9lbFHA.456@TK2MSFTNGP09.phx.gbl...
> The issue is that these methods are executing under BizTalk 2004. This
> means that the VB6 components are being called from ThreadPool threads
> which will enter the MTA and so all the VB6 components will join the Host
> STA (all of them will be serviced on the same thread) which is not good
> for scaleability.
>
> One solution would be to write a .NET component that managed a custom
> thread pool of STA threads and ran a number of VB6 objects in those STAs.
> However, this is a non-trivial thing to build (and to some degree is a bit
> like reimplementing part of MTS ;-) ) - which thinking about it could be
> another solution - to host the VB6 components under COM+ and use COM+s
> threading infrastructure to provide the multiplexing.
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://www.dotnetconsult.co.uk/weblog
> http://www.dotnetconsult.co.uk
>
>   Just to make sure we are talking about managed code here.
> Your VB6 COM objects are created and accessed from from C# (.NET) managed
> code right?
>
> Willy.
>
>
Author
10 Jun 2005 9:04 AM
Venkat
how will it solve the problem if i change like that? any technical articles /
proofs, substantiating your view?

pLS..
VENKAT.

Show quoteHide quote
"Willy Denoyette [MVP]" wrote:

>
> "Venkat" <Ven***@discussions.microsoft.com> wrote in message
> news:71D078A4-EBFE-4A92-A585-915F239D62BD@microsoft.com...
> > Hi,
> >     We have a dozens of VB6 components, developed some 5 years before, we
> > have now  few .Net components which references these files. Ideally we are
> > using Biztalk server and referencing these VB6 components into that, what
> > happens is that during actual transaction with several instances, the
> > process(biztalk)
> > gets automatically shutdown.
> >
> > on researching the problem it was found that all VB6 compentes were STA
> > and
> > so when loaded into memory it caused a deadlock problem. The solun ideally
> > is
> > to convert all the vb6 componets to .net components, but as of now this is
> > practically impossible.
> >
> > can any one suggests an alternate method so that the process goes with MTA
> > instead of STA or atleast any ways to minimise the deadlock condition?
>
> Simple solution is to create/access instances of those COM objects on/from a
> STA threads, that is initialize your threads as STA by setting the
> ApartmentState to STA before starting the thread.
>
> Willy.
>
>
>

Bookmark and Share