Digging a little into MSMQ and how it can help me with a website tracking mechanism I'm working on, I've come up on an original idea posted by Don Demsak in his blog.
Don suggests that when you need to have ASP.Net session state distributed across several web servers, you can possibly use MSMQ subqueues (a new feature in MSMQ 4.0) for storage. That is, ASP.Net could have one logical queue for each session its storing and use that to store the session data in a distributed fashion.
This might prove to be faster and more scalable that sharing Session State through a database, but I don't quite see how this can compete with a dedicated distributed session state solution like, for instance, ScaleOut's.
One quote that struck me as particularly important to remember for the future is:
"The first issue I've run across is that System.Messaging wasn't updated in .Net 3.5 to take advantage of MSMQ 4.0. Reading from a subqueue is the same as reading from a regular queue, but you can't write to a subqueue using the System.Messaging namespace."
Remembering details like that is one of those things that you don't know when you're going to need but you're sure you will. Lucky I have a blog for that. Thanks Don.
How I found DonXml's blog is a story onto itself. I used Summize and TweetScan to search for people who recently mentioned MSMQ in their Twitter posts. Don was one of the people that Summize found for me and he was very kind in answering a few questions I had about MSMQ. TweetScan found considerably less results than Summize did BTW.