Architecture For C#/.NET 4.0 Custom SessionState Provider/ Module /SessionItems Collection Class Lib?

This question pertains to writing a massively scalable & efficient customer sessionstate class library in C# and I am in desperate need of sage counsel.

Original thread that has been guiding me based upon:

I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it

Hope this thread can be called back from the netherworld as I have been spending the past 48 hours (with a few power naps) trying to implement the ideas elucidated here and I must admit I am somewhat lost in the solution space and would be grateful for some clarity.

Allow me to explain where I am at & what is confusing me & what I am trying to accomplish. The back & forth here with James & Joel raises great points but concrete implementations beyond the links leave me somewhat in the dark.

I'm trying to create a class library/dll I can use in several of my projects to bypass the default sessionstate options of inproc, sql & stateserver. This is somewhat new to me so please excuse my ignorance. Further I am somewhat of a down & dirty asp.net / C# coder and some of the more subtle nuances of generics, thread safety, locking, and serialization do tend to hurt my little head :))

I had started by creating a custom sesion state provider based upon a sample I found on MSDN that writes to access. Then I had found this page and Pandora's box was wide open and now I cannot get the genie back in the bottle. I dug more and I found a template for a custom sessionstate module and I added that too to my class library. SO nowwwww... I have both a provider and module of my own and then after reading Joel's many tips I ended up creating a custom session state items collection based upon yet another sample I found on MSDN.

That was originally based upon a hashlist, somehow I ended up turning it into a sortedlist, and then I seem to have followed Joel's steps one by one as pertains to the following:

lock(typeOf) rewritten in all .cs files to use lock(thisLock) where thisLock is a private static object as per the Rico article mentioned here ... I do understand the "concept" of deadlocks but this is my first attempt to scale an asp.net site and I am not feeling like Joe Architect quite yet. I cannot afford to be lazy here because I do not wish to build upon a shaky foundation only to get a bunch of hard to figure out bugs further on up the road.

Then I followed Joel's advice about the "slim" version of the locks and got that working in my classlib as well. And yet still my spider-sense is tingling telling me I basically still am in obedience mode rather than enlightenment mode, i.e. I don't have the NEO style vision of 1s & 0s dancing in my perceptual field.

So I keep coming back to this page like a refugee from a Dan Brown novel and now I am looking at the final admonition by Joel advising that until the sessionstateitem collection is made threadsafe no good can be assured in the multiverse. So I figure it is time to start brushing up on threadsafe collections.

That's when I start reading an article by MSFT on http://msdn.microsoft.com/en-us/library/dd997305.aspx SortedLists & other oldies but apparently no开发者_高级运维t so goodies being deprecated in favor of generics. Now I have actually created entire business layers and linq layers that are serializable and are used for shopping carts and stored in an offline database.

But the truth is sessionstate, threadsafety, using BOTH module & provider, and the lack of any samples here to debug has my cerebral drive continuously redlining and the heat sink is faltering.

MSFT says in above link, "The collection classes introduced in the .NET Framework 2.0 are found in the System.Collections.Generic namespace. These include List, Dictionary, and so on. These classes provide improved type safety and performance compared to the .NET Framework 1.0 classes. However, the .NET Framework 2.0 collection classes do not provide any thread synchronization; user code must provide all synchronization when items are added or removed on multiple threads concurrently.

We recommend the concurrent collections classes in the .NET Framework 4 because they provide not only the type safety of the .NET Framework 2.0 collection classes, but also more efficient and more complete thread safety than the .NET Framework 1.0 collections provide.."

So James sorta bolted thru the exit saying I got it, and that's the end of the thread but I have experienced some very peculiar behavior while debugging.

1. I am using a harness website to test my session lib. If I specify BOTH the httpmodule and the custom provider only the module runs in the harness/testing site I whipped up. BUT- if I modify the web.config of a real mature codebase it opts for the provider.

I did realize I could use one at a time to get the harness site pointing to the provider by not using the module.

That is fine for now but then I found myself saying to myself, "self.... you have a custom collection but is it threadsafe, are we still locking it, should we be locking it from outside the collection, i.e. in module or provider? My brain is saying is "thread-safety" encapsulated in the collection itself.

And how do I really know that all these slow page.aspx/longpage.aspx samples where one must hang out waiting for a thread to finish, even if user has click another link in frustration (what frustration? on a web site? perish de thought!)...

So basically, like Bugs Bunny, hangin' from the smithereen remnants of la bella luna I beseech thee, "GET ME OUTTA HERE..."

I thank you in advance for your timely consideration in this matter & others of monumental importance.

Best,

Cary Abramoff, MCSD.NET (Ten years of .net & I still wish it were all JQUERY baby!)

---

Sounds like what you really need to do next is create a testing program that calls multiple pages in your harness site simultaneously. This will simulate the situation that locking is meant to benefit and it will also help you determine if your implementation is logically correct. Without that I think you're sort of working at this blindly.

Hope that helps.

On a side note: I am currently working on a custom session state provider backed by Redis. My plan is to have an implementation that allows the locking to be turned off. I will likely get open sourced on Github once it is stable.