STA and MTA

[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?

[Willy Denoyette [MVP]]

"Venkat" <Ve****@discussions.microsoft.com> wrote in message
news:71**********************************@microsof t.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.

[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

[Venkat]

I didnot understand, can you be more specific with an example?

venkat.

"Willy Denoyette [MVP]" wrote:

"Venkat" <Ve****@discussions.microsoft.com> wrote in message
news:71**********************************@microsof t.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.

[Venkat]

how will it solve the problem if i change like that? any technical articles /
proofs, substantiating your view?

pLS..
VENKAT.

"Willy Denoyette [MVP]" wrote:

"Venkat" <Ve****@discussions.microsoft.com> wrote in message
news:71**********************************@microsof t.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.

[Willy Denoyette [MVP]]

"stic" <st*************@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.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/de...e0bf3889af.asp
Or are you looking for something else?

Willy.

[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.

"Venkat" <Ve****@discussions.microsoft.com> wrote in message
news:D4**********************************@microsof t.com...

I didnot understand, can you be more specific with an example?

venkat.

"Willy Denoyette [MVP]" wrote:

"Venkat" <Ve****@discussions.microsoft.com> wrote in message
news:71**********************************@microsof t.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.

[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.

[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.
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:uu*************@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.