I've started looking at re-writing some pages on a clients website and I can see that for example as soon as somebody logs in there are 53 Sessions variables set. To me this seems crazy to set everything as soon as you login and then throughout the website either refer back to these sessions or add new ones. More often than not their site receives errors because one of the many Sessions has lost its value. So my question is what is the best way of re-doing these pages. Is it a good idea to continue using this amount of Sessions? Is there a better alternative of using the Sessions? There are some variables that are needed on ALL pages on the site so is it better to retrieve these from the Database on each page or set these in a Session? I believe that there should only be one Session needed and that is the USERNAME/USER-ID and everything else should be grabbed from the database as and when it is needed. Thanks in advance

It's generally not a good idea to use session so heavily, but it depends on what kind of data is being stored there. If it's a bunch of string and integer values it's probably not too much of a concern, but if they're storing robust objects and/or large sets of data in session, I would definitely look into refactoring it. As a rule of thumb, I try to avoid using session for anything other than user-related data. It can be tempting to use session for purposes other than this, but with a good design and implementation you shouldn't really need to. Here are a couple of guiding principles on where to store things: For data that is user-specific and is accessed frequently throughout the application, utilize session to reduce trips to the database For data that is more or less static and not dependent on or related to the user, utilize cache or application state to reduce trips to the database For data that is page-specific, utilize ViewState and/or hidden fields. However, do not use ViewState to store large objects or sets of data For data that is considered safe for users to see, consider using QueryString to pass information from page to page The above principles will usually guide you in the right direction, but as with anything there are exceptions. Just be thoughtful of where you're storing data and why you're storing it there, and you should be fine.

asp.netsession-variables

Jamie Taylor

Reputation: 3530

Using Sessions throughout a website

I've started looking at re-writing some pages on a clients website and I can see that for example as soon as somebody logs in there are 53 Sessions variables set.

To me this seems crazy to set everything as soon as you login and then throughout the website either refer back to these sessions or add new ones.

More often than not their site receives errors because one of the many Sessions has lost its value.

So my question is what is the best way of re-doing these pages.

Is it a good idea to continue using this amount of Sessions?
Is there a better alternative of using the Sessions?
There are some variables that are needed on ALL pages on the site so is it better to retrieve these from the Database on each page or set these in a Session?

I believe that there should only be one Session needed and that is the USERNAME/USER-ID and everything else should be grabbed from the database as and when it is needed.

Thanks in advance

Upvotes: 3

Answers (3)

James Johnson

Reputation: 46047

It's generally not a good idea to use session so heavily, but it depends on what kind of data is being stored there. If it's a bunch of string and integer values it's probably not too much of a concern, but if they're storing robust objects and/or large sets of data in session, I would definitely look into refactoring it.

As a rule of thumb, I try to avoid using session for anything other than user-related data. It can be tempting to use session for purposes other than this, but with a good design and implementation you shouldn't really need to.

Here are a couple of guiding principles on where to store things:

For data that is user-specific and is accessed frequently throughout the application, utilize session to reduce trips to the database
For data that is more or less static and not dependent on or related to the user, utilize cache or application state to reduce trips to the database
For data that is page-specific, utilize ViewState and/or hidden fields. However, do not use ViewState to store large objects or sets of data
For data that is considered safe for users to see, consider using QueryString to pass information from page to page

The above principles will usually guide you in the right direction, but as with anything there are exceptions. Just be thoughtful of where you're storing data and why you're storing it there, and you should be fine.

Upvotes: 3

mgnoonan

Reputation: 7200

It does depend on your situation, but I would examine and justify why you need each of the 53 session variables. While this is not unheard of, you have to account for how much RAM your session storage is going to take as it can impact the number of concurrent users that your site can support.

You can do as @walther suggests, but again I would want justification, as putting them in the database will trade an in-memory Session operation for a (network) database call. Maybe some of the values are really global, and not specific to the session? In which case you could move them to the Cache object.

Basically, examine their usage and come up with the appropriate storage scope. It's ok to leave them in Session, if that's what is necessary, but you need to understand the impact and the implications.

Upvotes: 0

walther

Reputation: 13600

First of all, I highly doubt you have multiple sessions per user, which would mean you're referring to session variables.

Secondly, it all depends on your goals, but, if you have this many variables, maybe you should use DB instead for storing them and retrieving when necessary. 53 session variables is certainly WAY TOO MANY for any website.

Upvotes: 0

Using Sessions throughout a website

Answers (3)

Related Questions