Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If it is vital you should only have a single call to the service at any time I recommend you write your own Windows Service. This depends on how much fault tolerance you want.</p> <p>Let's say for example you make a call to the web service, but then the application pool is recycled. When a new request comes in it would be handled by a new instance of your application which could then make the call to the web service (Even if the other instance is running). </p> <p>You could pass this off to a windows a service, then use a polling mechanism from the client to check if the service has finished (Client would ask IIS are you done, IIS would look for some indication from windows service that it was done). This approach will avoid locking anything in IIS, and you won't waste critical resources such as threads in your thread pool waiting on a third party service.</p> <p>You should never lock on a single resource in your web application...it's just too risky. </p> <h1>Edit</h1> <p>Another option is to use the Monitor object directly:</p> <pre><code> if (System.Threading.Monitor.TryEnter(syncObj,10)) { try { //CallWebService } finally { System.Threading.Monitor.Exit(syncObj); } } else { //Tell Client they are still waiting } </code></pre> <p>TryEnter will block until a lock is made or 10 milliseconds has passed. You could then in your timeout tell the client they need to retry. You could then have your client code decide if it should reissue the request. You could also use a semaphore or mutex (forget which one is more appropiate here). But it would assuming you have permissions to use them, give you something you can lock on at the machine level which would prevent the app recycling use case.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload