Some web applications need to impersonate a user account for one reason or another. This is done from web.config and could look like this:
<identity impersonate="true" />
Threading
The impersonation works fine, but if you create new threads manually you would lose the impersonation if you don’t move it along to the new thread. This gave me a severe headache before I figured out how to pass the impersonation to the newly created thread.
What you need to do, is to pass the
WindowsIdentity object to the new thread and from there impersonate again manually. Here is an example of how to do it using the ThreadPool:
public void StartAsyncCall()
{
System.Security.Principal.WindowsIdentity identity = System.Security.Principal.WindowsIdentity.GetCurrent();
ThreadPool.QueueUserWorkItem(RunAsyncCall, identity);
}
private void RunAsyncCall(object stateInfo)
{
System.Security.Principal.WindowsIdentity identity = (System.Security.Principal.WindowsIdentity)stateInfo;
identity.Impersonate();
DoSomething();
}
As you can see, it is pretty simple once you know how.
ASP.NET has an outgoing connection limit which is set to 2 connections by default. It means that the ASP.NET process does not create more than 2 concurrent connections simultaneously, but instead queues them up.
Consider the scenario where you call 4 web services asynchronously from the same method. What happens is that the first two starts to execute, while the next two waits for the first two to finish. The same thing happens for HttpRequests.
That is a waste of time in most cases, so you can raise the connection limit to allow more simultaneous reqests in the web.config.
<system.net>
<connectionManagement>
<add address="*" maxconnection="8"/>
</connectionManagement>
</system.net>
Every asynchronous request is started in its own thread, so you have to be careful not to raise the limit too far. The more CPU’s or cores the web server have, the higher can you set the connection limit.
You can read more about asynchronous requests and the connection limit on MSDN.