[SOS] is for Save our State
So your next game is to actually build a web application (using ASP.NET 2.0) , web applications are means that you give to users so they can either view, enter or modify data that will be eventually lands to either local/remote DB or be used to remote calls (you name it WCF/Web Services/MSMQ whatever). However one thing that we all know – should I say struggle with – is saving state between page, the reason for struggle is the impact on performance specially if you are planning to deploy your application to serve large amount of users.
To name the challenge: you want to save state in-between pages and you want to know the best ways.
If you are building a web application you will end up with one (or mixture) of the following approaches:
- Session State
o Where is it: on server memory
o What to save: anything from memory references (variables) to serialized data.
o Scope: user’s (users do not share values) session on server, according to your configuration. However default is 20 mins from the last request.
o How it works:
Generally think of it this way, an empty bucket is created on the server memory, you fill it each time you write Session.Add, remove from it using Session.Remove or clear it using Session.Abandon (or cleared 20 mins after the user last request), this bucket is labeled on 2 levels
· A label which you cannot control (placed outside the bucket) called sessionID, used by the runtime to locate the session (among million of users the runtime need to locate one bucket that actually belongs to the current logged on user, it is actually the current thread).
· A label for each variable placed inside the bucket and that you control in the add/remove function call parameters
However how the runtime knows how to locate this bucket for this user, basically via leaving the value of the label (the one placed outside the bucket) somewhere on the client side, each time the client makes a call to the server this value is communicated.
§ Option A (default):
· Cookie is left to the browser, the browser will be sending the cookie each time a page is requested, this option doesn’t work if the user disabled the cookie on the browser and/or a cookie blocker is in action
§ Option B (using web.config)
· Instead of leaving the value of the label on a cookie, the value is actually appended to the URL hence the name “cookieless sessions”, once you enable this the URLS is automatically will have this value (hence during the development never relay on the URL communicated in the header instead use appreciate calls) so whenever you enable this feature, your code works fine.
Be aware these values are saved in server memory, so you are consuming valuable resources each time you are using session variables. So it saved in server’s physical memory, what if I want to go for a multi-server environment (also known as Server Garden) or actually using (Web Garden) feature of ASP.NET now you have sessions being saved in deferent memories. What you can do to work around that is
Use (ASP.NET out of the box feature)
o ASP.NET session service: by which you create a server that does nothing other than acting as centralized memory store for sessions, that definitely degrades the performance since each time you are doing session calls you are doing cross network calls
o SQL server as session store that however also degrades the performance since each time you do session calls you are doing SQL calls.
be aware that to use these options you are safer using serialized variables.
Finale: obviously with all of the above session variables are evil and probably you are better off not using them; except when you really REALLY need them.
Next entry will be on application Variable….