Its been a while since i posted , almost 4 months now, was busy with office work.
So in this post I would like to talk about ASP.NET sessions.
Ok...now we all know about ASP.Net sessions, we all know there are few methods which you can use to store session information, one common way and default way is store session state in the memory of the machine in which ASP.NET is running, the other way is to use the ASP.Net state server or to use the default SQL Server provider to store session data, we are not going back to the basics however, we should be careful in choosing where the session data will be stored and what sort of data will be stored.
It's particularly important to know that moving session data from one mechanism to another (in proc to state server)is not just a matter of changing the configuration file.
When using in-proc data is stored in memory, but when storing it in the state server or on a database like SQ Server, these session data needs to be serialized.
Not all data is serializable, like for an example the generic Dictonary or XElement class, so you have to be careful of what you store in the session, if your thinking that in the future you might go for a State server.
It depends on what data is stored in the session, for an example, the best thing for you to do is to store very less data in the session so that you don't use up a lot of server memory for storing user data.
There is also sometimes when you would want to store view State data in the session, hence, the amount of data that goes back forth from the user browser to the server is minimized, here is an MSDN Link on how you can do that.
So in this post I would like to talk about ASP.NET sessions.
Ok...now we all know about ASP.Net sessions, we all know there are few methods which you can use to store session information, one common way and default way is store session state in the memory of the machine in which ASP.NET is running, the other way is to use the ASP.Net state server or to use the default SQL Server provider to store session data, we are not going back to the basics however, we should be careful in choosing where the session data will be stored and what sort of data will be stored.
It's particularly important to know that moving session data from one mechanism to another (in proc to state server)is not just a matter of changing the configuration file.
When using in-proc data is stored in memory, but when storing it in the state server or on a database like SQ Server, these session data needs to be serialized.
Not all data is serializable, like for an example the generic Dictonary or XElement class, so you have to be careful of what you store in the session, if your thinking that in the future you might go for a State server.
It depends on what data is stored in the session, for an example, the best thing for you to do is to store very less data in the session so that you don't use up a lot of server memory for storing user data.
There is also sometimes when you would want to store view State data in the session, hence, the amount of data that goes back forth from the user browser to the server is minimized, here is an MSDN Link on how you can do that.
In the above case, that is where you can do real bad then good, cos' you might be storing data that needs to be persisted on a post back, these might include small data sets to a few custom objects.
These are some of the cases where you can go wrong when you stat storing data in sessions and you are moving from in proc to database or state server...
1) You create an annoynmous type and bind it to a grid, well annoynmous types are not serilizable hence, this will not work if you are using the state server or a database to store session data. You would have to create a wrapper type, and use this to be stored in the session.
2) Any objects that has a property of type XElement, unfortunately this type is not serlizable, hence you would have to use either XmlDocument to store the representation of XElement or take to step explained below on the 3rd point.
3) If you are storing one of your custom types, these have to be marked with [Serilizable] attribute, however there are some cases where you would inherited from a class that is not marked as serilizable, marking your implementation Serilizable wont do any difference, one way to come around this problem maybe to use an XmlSerlizer to serialize the object into XML representation and then store the text in the session (there is a overhead here...)
All the 3 steps mentioned have there overheads, so choose wisely on what data is stored inside session.
P.S Some of these ideas came from Yohan S.
Comments
Post a Comment