Hi, What Phil says about thread issues when doing interop is true (and clearly explained). Now your problem is maybe that you want to reuse this COM component because it encapsulates valuable business logic, even if it has been badly designed on a technical point of view.
You may then have a look at the application pooling feature of COM+ 1.5. This new feature has been introduced to enable the parallel execution of a single threaded legacy application. It is especially useful when you want to reuse legacy code that is currently running in batch mode. Very often this kind of code does not support multithreaded execution because it contains for example global variables. Once you have encapsulated this code in a C wrapper, you can do a DllImport in a serviced component. And then the application pooling enables you to isolate this legacy code and to control the number of applications you have in your pool. That maybe useful in your situation. You would not have to do the C wrapper bit because you are dealing with a COM component. But the application pooling can enable you to isolate your COM component which is not thread-safe, and at the same time to offer parallel execution of this legacy code. The drawback of this feature is that it is only available in COM+ 1.5 which is not part of Windows 2000. COM+ 1.5 is only available in WinXP (for development purposes) and WS2003. Jerome Grelier > -----Message d'origine----- > De�: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] De la part de Phil Parker > Envoy�: mercredi 12 mars 2003 00:54 > ��: [EMAIL PROTECTED] > Objet�: Re: [ADVANCED-DOTNET] Interfacing with a non thread-safe COM API > > On Tue, 11 Mar 2003 12:22:04 +0530, Mihir Pathak <[EMAIL PROTECTED]> > wrote: > > > > > > >-----Original Message----- > >I am trying to integrate with a particular back end application that has > >a non thread-safe COM API. From an integration perspective, multiple > >front end users will probably result in the back end API getting called > >in a manner that requires multi-threaded behavior (the ability to run > >multiple processes in parallel). Given this, I'd like to find out if > >there are any workarounds at the COM layer to circumvent this problem. > >I'd really appreciate any approaches that have worked in the past, > >ideas, etc. > > > >Mihir. > > > > > > If by a non thread-safe COM API, you mean you are interfacing with an > existing STA based COM API, then this will be handled automatically for > you > by COM interop - in this case, any calls from managed code will be > serialized as expected to the STA apartment's thread. > > If you're dealing with an MTA COM component, then the developers should > have implemented thread concurrency management on the component itself. > If > not, they are breaking COM rules and you would also have problems using > this component from multiple threads with legacy COM clients. > > If you're going to be doing a lot of interfacing with COM, you may want to > consider buying Adam Nathan's excellent book '.NET and COM - The complete > interoperability guide". > > Phil Parker. > > =================================== > This list is hosted by DevelopMentor� http://www.develop.com > You may be interested in Guerrilla .NET, 24 March 2003, in London > http://www.develop.com/courses/gdotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com You may be interested in Guerrilla .NET, 24 March 2003, in London and Boston http://www.develop.com/courses/gdotnet View archives and manage your subscription(s) at http://discuss.develop.com
