locked
SESSION VARIABLE WHERE TO STORE RRS feed

  • Question

  • User1480781148 posted

    Hi Friends,

    As I  am developing asp.net web will be deployed on  internet , I stored data table in session variable, I want to inquire which is best way of storing session variable, in database or in memory.

    thank you.

    Regards,

    asad

    Monday, November 17, 2014 9:24 AM

Answers

  • User-484054684 posted

    so we should  store them in  sqlserver, that 's the  only option available at last

    View state can still be used, as long as:

    1. You are not storing any sensitive information in it.

    2. The data is not huge.

    3. You want to use the data only with in the same page.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, November 17, 2014 11:17 AM

All replies

  • User-484054684 posted

    The main difference between database or in memory, is:

    If we have the web application hosted in single server we go with in-memory (in-proc) storage (that is, IIS).

    If the application is hosted in multiple servers (web farm) we need to go with out-of-proc session (SQL server or State server modes).

    Monday, November 17, 2014 9:36 AM
  • User724169276 posted

    As I  am developing asp.net web will be deployed on  internet , I stored data table in session variable, I want to inquire which is best way of storing session variable, in database or in memory.

    Hello,
    As the session usage increases wastage of memory will happen too often if number of users are more.So its best to save values in cookies.That's what most of websites now a days follow.Even this forum uses cookies to save user session (Not the session variable).

    Monday, November 17, 2014 9:50 AM
  • User281315223 posted

    As I  am developing asp.net web will be deployed on  internet , I stored data table in session variable, I want to inquire which is best way of storing session variable, in database or in memory.

    You may seriously want to reconsider this as the Session can be a bit of a slippery slope and should generally be avoided for any types of persistent storage (this is especially true of systems with a large number of users).

    Some users believe the Session can be great for performance and generally users will experience this extremely fast speed when accessing values from it. This is because your actual data is going to be stored in memory for each user within your application so when it is accessed, there isn't really any request that is going to be made to pull it. This creates a huge bottleneck in terms of resources for your application and can really come back to bite you if you have a large number of users or data :

    (Number of Users) * (Size of Session) < (Server Memory / Resources)

    If this value is exceeded, you could encounter an OutOfMemoryException and your application / web server would likely be restarted (clearing out the Session). This is just one of the many reasons that the Session isn't terribly "reliable" if you need any sort of data persistence. Any number of things could cause the Session values to be wiped, which may or may not be in the middle of someone attempting to fetch them.

    If you really need to store values or pass them around your applications, there are quite a few options out there that won't hamper your actual server down : 

    • Using Forms - If you just need to pass values from a single page to another, you could always POST the values by defining the target page that you want to pass the values to within the "action" attribute of your <form> within your ASPX page. This will make any element with a name attribute accessible through the Request collection.
    • Using the ViewState - This is another option although it is a bit similar to the Session, but it will only persist the values while on a single Page. This can be useful if you are going to continually post back and forth to the same page and need to access some previously used data.
    • Using the QueryString - If you need to make a single request to pass values from one page to another, you could consider populating several variables within the QueryString parameters of a Reponse.Redirect() request and passing them along. Every value that was passed along would be accessible within the Request collection within your target page.
    • Using Cookies - If you need to persist your values or data throughout multiple pages and don't want to use the Session, you can store your values within cookies in the browser. Cookies are far more hearty than the Session and as long as the browser supports them, they will store your values through browser closures, IIS restarts and much more.
    • Using a Database - Finally, the most persistent form of data, which may generally be overkill for many situations, would be to store your values within a database. This should really only be used if you need to store the data long-term or need to persist it through different systems and various other scenarios.

    As you can see, there are quite a few alternatives to the Session, and I would recommend looking into each of these as they will allow you to built a much more tolerant and scalable solution.

    Monday, November 17, 2014 9:55 AM
  • User1480781148 posted

    thank for reply, actually I am storing data table , I think no way I cannot store data table into cookies, further I had used viewstate but I faced difficulty while data inserting or deletion in data table, although I am store session variable for single page I am not transfer them into multiple pages. 

    so the remaining option available is to store session variable into database I believe it will be as fast as storing them into memory, I using single server for database and for IIS, please let me know if  have any recommendation to store session variable in database.

    thank you.

    Regards,

    asad

    Monday, November 17, 2014 10:34 AM
  • User-484054684 posted

    further I had used viewstate but I faced difficulty while data inserting or deletion in data table

    The syntax to get/update Session variable is same as that of ViewState. So, ideally you shouldn't face the problem in using one mechanism if you know how to use other mechanism.

    although I am store session variable for single page I am not transfer them into multiple pages. 

    Generally if the data that will be used with in the page, then Session will not be used and as you specified ViewState is one of the alternatives.

    so the remaining option available is to store session variable into database I believe it will be as fast as storing them into memory,

    It depends on the website load. If there are more number of users, then more server resources will be consumed and even getting the data from IIS may be slow in such case. But if the users are less, then retrieving from IIS will be faster. Remember, the moment you go for multiple servers - inproc is not right option.

    On the other hand, getting the session from SQL will need another call to SQL to fetch the records. Under the hood, the data will be stored in serialized format and to get it into object, the deserialization will be performed by server. So this is a bit of overhead - but SQL storage is most reliable as the data will not be lost even if the application pool is recycled or IIS is restarted etc.

    Monday, November 17, 2014 10:51 AM
  • User1480781148 posted

    so finally lets conclude that in multiuser environment the session should store into sqlserver, what's is your opinion  to use viewstate since I am storing them into  single page.

    thank you.

    regards,

    asad 

    Monday, November 17, 2014 10:57 AM
  • User-484054684 posted

    The scope of the ViewState's data is for single page, as you rightly understood. Note: The data will be stored in hidden fields of the page (though encoded) - so there is a security threat if you are storing any sensitive data.

    Also note, having large amount of data stored in view state will also cause performance problems - because the data needs to go back-n-forth between the server<->client during HTTP round trips.

    Monday, November 17, 2014 11:03 AM
  • User281315223 posted

    so finally lets conclude that in multiuser environment the session should store into sqlserver, what's is your opinion  to use viewstate since I am storing them into  single page.

    The ViewState should be fine if you are using a single-page storage scenario (e.g. PostBacks will persist data within a single page), however if you need any more persistence, you'll likely want to consider using a database for your storage.

    Monday, November 17, 2014 11:08 AM
  • User1480781148 posted

    so we should  store them in  sqlserver, that 's the  only option available at last

    Monday, November 17, 2014 11:09 AM
  • User-484054684 posted

    so we should  store them in  sqlserver, that 's the  only option available at last

    View state can still be used, as long as:

    1. You are not storing any sensitive information in it.

    2. The data is not huge.

    3. You want to use the data only with in the same page.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, November 17, 2014 11:17 AM
  • User1480781148 posted

    thank you for reply, its ok

    Monday, November 17, 2014 11:19 AM
  • User281315223 posted

    so we should  store them in  sqlserver, that 's the  only option available at last

    No, it isn't the only option. 

    The ViewState as mentioned will be a completely fine option for this (assuming you only need to persist the values on a single page as you mentioned). If you need anything further than this (e.g. persisting the values across multiple different pages, which the ViewState cannot do), then you'll want to look into something like a database.

    Monday, November 17, 2014 11:22 AM
  • User1480781148 posted

     viewstate I faced problem , I could not delete record from datatable which was stored in viewstate.

    Monday, November 17, 2014 11:28 AM