Multithreading and Com object

Question

Hello,

I have a situation where I have a piece of software that I need to call from a .Net web service.  This software is accessible through a System.Runtime.Interopservices wrapper.  Within the software, it can support 8 simultaneous transactions in memory.  Each transaction keeps its own ID and objects that stay resident in memory until individually deleted when finished.  Also the software has an initialize function that caches its database and a cleanup function that destroys all the transactions and frees the memory.

I am fairly new to multithreading and I could really use some advice on how to monitor the 8 transactions, especially since calling from a webservice.  In a single thread, I can loop through these and not have an issue but calling it from a webservice, I need to monitor the concurrent lookups and make sure that I don't go over 8 concurant ones.

I would greatly appreciate any advice.

Thanks,

Answer 1

Please try threadPool http://msdn.microsoft.com/en-us/library/system.threading.threadpool(v=vs.100).aspx 

Have a nice day.

---

Ghost,
Call me ghost for short, Thanks
To get the better answer, it should be a better question.

Answer 2

How are your these 8 transactions are being executed? Is it sequentially or with 8 parallel threads? In a without web service scenario how you monitor these transactions? (Can you share few lines of code here?)

Looking to your problems statement, you can use Multithreading using Thread Pool or Asynchronous programming model to achieve it. Please note that, Inside the ASP.Net Worker Process there are two thread pools. The worker thread pool handles all incoming requests and the I/O Thread pool handles the I/O (accessing the file system, web services and databases, etc.). Each App Domain has its own thread pool and the number of operations that can be queued to the thread pool is limited by the configuration like,

<system.web>
  <httpRuntime minFreeThreads="8"
	 minLocalRequestFreeThreads="4"  />
  <processModel 
	maxWorkerThreads="100" 
	maxIoThreads="100"  />
</system.web>

If you want to restrict that at a given point only 8 threads (transactions) are going to be executed then you can use restrict it by using ThreadPool. SetMaxThreads() to 8. Or Refer http://www.williablog.net/williablog/post/2008/12/02/Increase-ASPNET-Scalability-Instantly.aspx

If your issue is just to monitor about these 8 transactions running asynchronously you can use Delegate.BegineInvoke and use a AsyncResult to keep track on these transactions.

Codeblock:-

AuthorizeDelegate ad = new AuthorizeDelegate(AuthorizePayment);
IAsyncResult ar = ad.BeginInvoke(creditcardNumber,  
                                 expiryDate,        
                                 amount,            
                                 null,             
                                 null);            
// Poll until the asynchronous operation completes
while (!ar.IsCompleted)
{
  // Do some other work...
}
// Get the result of the asynchronous operation
int authorizationCode = ad.EndInvoke(ar);

following link would help you to know more.

Design and Implementation Guidelines for Web Clients

---

Lingaraj Mishra

Answer 3

With a limited resource like that, it could be useful to use an instance of the Semaphore class and set the limit to 8.

Answer 4

Hi Aaron,

Do you have any update?

How about this issue now?

Best regards,

---

Mike Feng
MSDN Community Support | Feedback to us
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 5

Thanks for your suggestions. In doing some research on this I learned that buy default, even though IIS is by nature multi-threaded, it creates a single threaded call to the com interface and makes requests in queue. I still have not learned exactly how this works but I guess it makes sense considering how it was developed in conjunction with ASP before parallel processing became widely used.  I am hoping that the article that I read on this is true.  I'll put a post on here if this turns out not to be the case.

I am still unclear on the best way to create a monitored wrapper around this process but it sounds like the semaphore class is a step in the right direction. Since IIS is supposed to call com interfaces in a single pooled connection, I may be able to get by without a lot of thread management here but I still want to be able to monitor this process.

I don't entirely know if this is true or has been changed over time so I am going to have to test it. I also don't like relying on IIS to handle the com interface correctly because it will probably change at some point.

Thanks again for your suggestions, I'll keep you updated as I test this out.

Answer 6

Hi Aaron,

Thank you for this update.

And good luck.

Best regards,

---

Mike Feng
MSDN Community Support | Feedback to us
Please remember to mark the replies as answers if they help and unmark them if they provide no help.