I’m using ASP.NET’s in-process session state store. It locks access to a session exclusively, and which means concurrent requests to the same session are served sequentially.
I want to remove this implicit exclusive lock, so multiple requests per session can be handled concurrently. Of course, I’ll be synchronizing access to the session state myself where it’s applicable.
I’m using the MSDN documentation of Session State Providers to write my own session state provider, and this SO question pointed me to this example code of implementing this as an HTTP module, but the code looks suspiciously complex just for the purpose of removing the lock.
I should probably eventually implement the session state using ASP.NET’s cache, and stop using the built-in session, like Vivek describes in this post, but for now how would I just like to remove the locking.
Any ideas or sample implementations?
Not the answer you’re looking for, but I think that even if it were possible, changing the way SessionState works in this way is a terrible idea.
Think of the poor guys who will have to maintain your code down the line. The fact that Session serializes requests in this way means ASP.NET developers often don’t need to worry too much about thread-safety.
Also if someone adds a third-party component that happens to use Session, it will expect the usual guarantees regarding locks – and you’ll suddenly start getting Heisenbugs.
Instead, measure performance and identify specific areas where you need requests to process concurrently – I bet there’ll be few of them – and carefully implement your own locking mechanism only for the specific items involved – possibly the solution that you’re planning eventually using the ASP.NET cache.