|
|
You're in the
dotnet component services
group:Asynchronous COM+ Method Calls?
dotnet component services:
If I have a COM+ method that returns results from a long-running database
query, is there a way to create a version of the method that uses one of the ..NET asynchronous calling patterns? Assume that I can use any technology I like. My interest is in creating asynchronous web pages for use in a high-volume web application. It's a bad idea to block the ASP.NET worker threads by, for instance, blocking on a COM+ method call. -- -------------------------------------------------------------------------------- John Saunders | MVP – Windows Server System – Connected System Developer
[quoted text, click to view]
> If I have a COM+ method that returns results from a long-running database query, is there a way to create a version of the method > that uses one of the .NET asynchronous calling patterns? Assume that I can use any technology I like. > > My interest is in creating asynchronous web pages for use in a high-volume web application. It's a bad idea to block the ASP.NET > worker threads by, for instance, blocking on a COM+ method call. Since Windows 2000, COM has supported asynchronous method calls. See http://msdn.microsoft.com/msdnmag/issues/0400/async/. Note that the implementation for the asynchronous architecture is confined to the proxy, so this should work just fine with COM+ objects. Personally, I have never used this support, preferring instead to launch a worker thread internal to the COM+ object to do my asynchronous work. Obviously you can do the same. Brian
[quoted text, click to view]
"Brian Muth" <bmuth@mvps.org> wrote in message news:OEJ0$7KSIHA.1208@TK2MSFTNGP05.phx.gbl... >> If I have a COM+ method that returns results from a long-running database >> query, is there a way to create a version of the method that uses one of >> the .NET asynchronous calling patterns? Assume that I can use any >> technology I like. >> >> My interest is in creating asynchronous web pages for use in a >> high-volume web application. It's a bad idea to block the ASP.NET worker >> threads by, for instance, blocking on a COM+ method call. > > Since Windows 2000, COM has supported asynchronous method calls. See > http://msdn.microsoft.com/msdnmag/issues/0400/async/. > > Note that the implementation for the asynchronous architecture is confined > to the proxy, so this should work just fine with COM+ objects. > > Personally, I have never used this support, preferring instead to launch a > worker thread internal to the COM+ object to do my asynchronous work. > Obviously you can do the same. Thank you very much. Not only do I not remember seeing that particular article; I also don't remember hearing any mention of async COM calls. "There must be something wrong with them", because they're too good to be true! -- -------------------------------------------------------------------------------- John Saunders | MVP – Windows Server System – Connected System Developer
Interface queueing is another option for long-running processes.
[quoted text, click to view] "John Saunders [MVP]" wrote:
> "Brian Muth" <bmuth@mvps.org> wrote in message > news:OEJ0$7KSIHA.1208@TK2MSFTNGP05.phx.gbl... > >> If I have a COM+ method that returns results from a long-running database > >> query, is there a way to create a version of the method that uses one of > >> the .NET asynchronous calling patterns? Assume that I can use any > >> technology I like. > >> > >> My interest is in creating asynchronous web pages for use in a > >> high-volume web application. It's a bad idea to block the ASP.NET worker > >> threads by, for instance, blocking on a COM+ method call. > > > > Since Windows 2000, COM has supported asynchronous method calls. See > > http://msdn.microsoft.com/msdnmag/issues/0400/async/. > > > > Note that the implementation for the asynchronous architecture is confined > > to the proxy, so this should work just fine with COM+ objects. > > > > Personally, I have never used this support, preferring instead to launch a > > worker thread internal to the COM+ object to do my asynchronous work. > > Obviously you can do the same. > > Thank you very much. Not only do I not remember seeing that particular > article; I also don't remember hearing any mention of async COM calls. > "There must be something wrong with them", because they're too good to be > true! > -- > -------------------------------------------------------------------------------- > John Saunders | MVP – Windows Server System – Connected System Developer > >
Another memory sparked:
I can't locate the source, but a reputable source noted that the .NET thread pool is quickly exhausted by high volume blocking COM+calls, resulting in a severe scalability issue. A recommended solution was to access COM+ components via async web service proxy, thereby returning the threads to the pool while the COM+ calls execute over SOAP. This results in a very clean, scalable solution. There is more call overhead resulting in slightly longer call times and increased network traffic, so this might be used for long-running processes only. [quoted text, click to view] "John Saunders [MVP]" wrote:
> "Brian Muth" <bmuth@mvps.org> wrote in message > news:OEJ0$7KSIHA.1208@TK2MSFTNGP05.phx.gbl... > >> If I have a COM+ method that returns results from a long-running database > >> query, is there a way to create a version of the method that uses one of > >> the .NET asynchronous calling patterns? Assume that I can use any > >> technology I like. > >> > >> My interest is in creating asynchronous web pages for use in a > >> high-volume web application. It's a bad idea to block the ASP.NET worker > >> threads by, for instance, blocking on a COM+ method call. > > > > Since Windows 2000, COM has supported asynchronous method calls. See > > http://msdn.microsoft.com/msdnmag/issues/0400/async/. > > > > Note that the implementation for the asynchronous architecture is confined > > to the proxy, so this should work just fine with COM+ objects. > > > > Personally, I have never used this support, preferring instead to launch a > > worker thread internal to the COM+ object to do my asynchronous work. > > Obviously you can do the same. > > Thank you very much. Not only do I not remember seeing that particular > article; I also don't remember hearing any mention of async COM calls. > "There must be something wrong with them", because they're too good to be > true! > -- > -------------------------------------------------------------------------------- > John Saunders | MVP – Windows Server System – Connected System Developer > >
[quoted text, click to view]
"caractacus" <caractacus@discussions.microsoft.com> wrote in message news:1594F668-0A78-4664-BCF7-D7991C648048@microsoft.com... > Interface queueing is another option for long-running processes. Thanks for the answer (though I had almost forgotten the question). But, what is interface queuing? Can you provide some links? -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view]
"caractacus" <caractacus@discussions.microsoft.com> wrote in message news:B2CB4DEE-2373-402C-ACDF-11ADEA4E4946@microsoft.com... > Another memory sparked: > > I can't locate the source, but a reputable source noted that the .NET > thread > pool is quickly exhausted by high volume blocking COM+calls, resulting in > a > severe scalability issue. This is true, and widely known. In fact, the general issue is that ASP.NET uses the thread pool to process incoming requests. If you then tie up those threads, for any reason (not just COM+), then you are reducing the number of threads available to process incoming requests. This can easily lead to a situation where all thread pool threads are busy doing nothing - just waiting for something to happen. When this happens, requests will be queued. After a while, they may even start being rejected with a "server busy" error code. [quoted text, click to view] > A recommended solution was to access COM+ components via async web service > proxy, thereby returning the threads to the pool while the COM+ calls > execute > over SOAP. > > This results in a very clean, scalable solution. There is more call > overhead > resulting in slightly longer call times and increased network traffic, so > this might be used for long-running processes only. This should work, though I'd recommend being careful to only expose your COM+ operations locally. I'd also suggest that this may be helpful for more than just long-running calls, if you get into the thread-pool starvation problem I discussed above. One question I have is whether there is one ASP.NET thread pool per Web Application or per worker process (aspnet_wp or w3wp). If only one per process, then you'll need to ensure that the COM+ "web services" are served on another worker process (different application pool). I'll also note that I've seen it mentioned that WCF can also expose COM+ components. See the "COM+ Service Model Configuration Tool". -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
April 2008
May 2008
| home · blog · groups | Questions? Comments? Contact the dn |