STA and MTA

[Guest]

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]]

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 ?

 

[Guest]

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

venkat.

 

[Guest]

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

pLS..
VENKAT.

 

[Willy Denoyette [MVP]]

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 ?

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/d...html/cb62412a-d079-40f9-89dc-cce0bf3889af.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.

 

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