Session variables

[Gerald]

Hi,

Is there any know problem using session variables ?
My website won't have more than 20 simultaneous connections, and i would
like to use 5 session variables containing strings...
I know than with ASP, it was not really recommended, what about ASP.NET ?

Thanks !

 

[Scott M.]

There's nothing wrong with using them, but there are better alternatives.

 

[Robbe Morris [C# MVP]]

Nothing wrong with them in ASP and there is nothing wrong with them in
ASP.NET.
Particularly value types like strings and ints.

 

[Gerald]

Thanks, wich alternatives are better ?

 

[Guest]

Hi,

Is there any know problem using session variables ?
My website won't have more than 20 simultaneous connections, and i would
like to use 5 session variables containing strings...
I know than with ASP, it was not really recommended, what about ASP.NET ?

Thanks !

Hi, i wouldnt call them problems, theres just stuff to be aware of. Like if
your site is spread across a web farm, youll need to use an out-of-process
session state instead of in-process. Also if that server gets rebooted then
ppl will lose their session state. But if theres only going to be 20 users
and 1 web server then there shouldnt otherwise be any real negatives to using
session state, as long as that server isnt running w/ 128MB of RAM!

HTH

 

[Scott M.]

Writing to a database, rather than saving per-user values in memory and
potentially needing to save huge amounts of data in RAM.

Using cookies for non-critical application data.

 

[Matt Berther]

Hello Scott M.,

At which point you're just offloading the bottleneck, right? Writing to/reading
from a database is one of the most expensive operations you can perform.

The true answer here is that Session variables used judiciously are ok. Issues
will come up if you do things such as storing every little detail in Session
or need to have session access across a web farm.

 

[Scott M.]

Reading/Writing to a DB is not the CPU and bandwidth hog that it once was.
This solution is widely considered to be the most stable and robust way to
persist state.

Now, should it be used to store short-term data or for every piece of data
needing to be persisted? No, and I never said it should be. I only said
that there are better alternatives to sessions (which, by the way, may not
even be an option since many web server admins turn off the server's ability
to use sessions because of the tendency to over use them or use them
incorrectly).

The *true* answer is that there is no one solution. The best sites use a
bit of several techniques where it makes sense to do so. I love using
cookies because it "off-loads" the storage to the client. But, as you know,
cookies can be turned off at the client level (as well as them being
susceptible to corruption). So, I only use them for non-critical data
storage like storing a user's preferences.

Sessions are easy enough to use, but can cause serious memory issues on the
server (even if they are used sparingly in code). Additionally, when a
client turns off cookies, they may also be turning of "per session cookies"
which means that server sessions are effectively turned off as well. Not to
mention the issues that come up with the use of sessions in web farm
environments.

Hidden form fields and querystrings are other ways to move data around but
they are also susceptible to corruption and querystrings in particular have
limits on the amount of data that can be passed.

So now we come to database storage....This can not be turned off by the
client, so it is reliable. There are no practical limits on the amount of
data that can be stored. Web Farm situations don't impact their use. The
possibilities of data loss due to a server crashing are eliminated, etc.,
etc., etc. Because we live in a world with faster servers and higher
bandwidth that ever before, using a database for persisting data is not the
taboo that it once was. Today, it is widely considered to be the "only"
choice by many serious web developers.