When I was a slip of a lad, my dad had some recordings (legitimate, I assure you) by a comedian/folk singer/now Radio 2 presenter called Mike Harding.
Whilst the subject matter was occasionally ribald for a 10-year-old, some of the songs really struck a chord, and I now remember them still.
One such song was called \”Some things that the grown-ups just don\’t tell you\” in which a child\’s inquiring mind asks such searching questions as \”If you eat food all different colours, why does it all come out brown?\” and \”If you undo your belly-button, does your bum really fall off?\”
With that in mind (and very much earwormed myself with that one), this leads me on continually discover things that should be easy to answer but turn out give the bum\’s rush when searching the internet.
The question I asked myself was:
\”When using SQL 2014 In Memory Session State, which elements of the application stack require .Net 4 or above?\”
Quite aside from the arguments against storing session state in the least performant manner in the first place, my google-fu deserted me for quite some time – definitive answers are hard to come by these days, it’s all ‘alternative facts’.
As a DBA, I understand that at the database layer, a recent version of .Net is required to handle the creation of natively compiled stored procedures that the ASPStateInMemory database schema requires, but does that necessarily apply further up the application stack ?
Logic would dictate not (in my view) – it\’s simply a Remote Procedure Call from the application or web service, and should therefore be agnostic as to the underlying technology. Shouldn\’t it ?
In a perfect world, yes, it very much should. But as we all know from recent history, the world is very much far from perfect.
ASPStateInMemory requires a new .Net provider. That provider is in .Net4, and is compiled using the CLR for that version.
You can\’t point an existing session state connection at the InMemory version without that.
So, if you\’re applications or services are compiled in .net 3.51, they\’ll be using the wrong version of the session state provider, written for CLR 2.0.
THIS MEANS:
If you\’ve not been diligent in keeping pace with the .net Framework versions in your development, or have existing legacy applications that would benefit from moving to InMemory session state, you can’t use ASPStateInMemory without re-writing them for the later version of the Framework.
The answer took me a while to find and then understand, but it appears the answer is:
\”All of your application stack.\”
…and *that* might be expensive…
Oh dear. Back to the drawing board then. I think I left some indexes over there… I\’ll just see how fragmented they are….
Back soon !
The Modern Dataist 