 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Component Services / March 2008Asynchronous COM+ Method Calls?
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.  Signature-------------------------------------------------------------------------------- John Saunders | MVP – Windows Server System – Connected System Developer > 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 >> 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 [quoted text clipped - 14 lines] > 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! Signature-------------------------------------------------------------------------------- John Saunders | MVP – Windows Server System – Connected System Developer Interface queueing is another option for long-running processes. > >> 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 [quoted text clipped - 19 lines] > "There must be something wrong with them", because they're too good to be > true! > 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? Signature-------------------------------------------------------------------------------- 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. > >> 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 [quoted text clipped - 19 lines] > "There must be something wrong with them", because they're too good to be > true! > Another memory sparked: > [quoted text clipped - 3 lines] > 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. > A recommended solution was to access COM+ components via async web service > proxy, thereby returning the threads to the pool while the COM+ calls [quoted text clipped - 5 lines] > 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". Signature-------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.