I'm guessing that the .NET collection class is likely AVL trees (in Knuth's Sorting and Searching) or red-black trees, in something by Sedgwick, and not hashing

I'm guessing that the .NET collection class is likely AVL trees (in Knuth's Sorting and Searching) or red-black trees, in something by Sedgwick, and not hashing, at least not normal hashing. E.g., hashing can have collisions. Sure, there is Ronald Fagin, Jurg Nievergelt, Nicholas Pippenger, H. Raymond Strong, 'Extendible hashing-a fast access method for dynamic files', "ACM Transactions on Database Systems", ISSN 0362-5915, Volume 4, Issue 3, September 1979, Pages: 315 - 344. with a graceful way around collisions. Our group used that paper in our work in a high end, cross memory (one address space gets data to/from another address space, calls code, etc. in another address space), active (generalization of, say, triggers common in relational database), dynamic (the object definitions change during execution) object store. There is also a good article with good details and some Python code at: http://en.wikipedia.org/wiki/Extendible_hashing http://en.wikipedia.org/wiki/Extendible_hashing Actually the code we used was nicely simple -- I have some notes someplace, but the paper itself is good enough documentation. But also have to have some persistence of the session state across different HTTP POST operations from the user; so, if have no user affinity with a particular executing instance of the Web server software, and I'm looking forward to having several executing instances of my Web server software, I want no such affinity, then I need something in a different Windows appdomain, e.g., http://msdn.microsoft.com/en-us/library/system.appdomain.aspx http://msdn.microsoft.com/en-us/library/system.appdomain.asp... process, address space, etc. like an external server for the session state data. Sure, that server could use the extendible hashing paper. But, since the .NET collection class is there, and no doubt by now used successfully more often than McDonald's has served a hamburger, I just used what Microsoft provided. I'm willing enough to beg, borrow, buy, or (hush!) steal a wheel instead of reinventing it! I did my DIY session state store partly because I guessed that I could write my own code in less time than it would take me just to understand how to use something highly regarded and off the shelf. I guessed that I wrote my code in less time than I would need just to understand Redis. That IBM work was intended as a high end object store -- I knew how hard it was to use something like that. And from some of my notes I see "Microsoft Unveils FASTER – a key-value store for large state management" as at https://www.microsoft.com/en-us/research/blog/microsoft-unveils-faster-key-value-store-large-state-management/ https://www.microsoft.com/en-us/research/blog/microsoft-unve... and https://news.ycombinator.com/item?id=17267403 https://news.ycombinator.com/item?id=17267403 But I discovered this option long after I wrote my own. Again, I suspect that I wrote my own is less time than it would take me just to understand the Microsoft documentation for their FASTER. If my DIY work gets weak in the knees from too much load, etc., then, sure, I'll consider options off the shelf.