locked
a lot of data in session vaiable is stopping the events in the page RRS feed

  • Question

  • User-1556678718 posted

    Hello,

    I have a very big dataTable in the session variable and it has to be there, and it can't be smaller. How do I increase the available memory for one page?

    Friday, August 24, 2012 1:23 AM

Answers

  • User-1179452826 posted

    It shouldn't be "stopping" the events. But realistically, DON'T put that much data into session. Perhaps store the data in a datastore and put the id of the entry into session. Just because a feature is there doesn't mean you should abuse it. And no, it doesn't "have to be there" - there are many ways of achieving the same result.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 1:48 AM
  • User-1179452826 posted

    Right...try to understand this - Session data is stored ON THE SERVER. By default, this is stored in SERVER RAM. If you want 30000 entries for each user stored in SERVER RAM, you will soon run into trouble. Your app pool will recycle KILLING the session ANYWAY. (This is most likely why you're getting the error). If you're convinced that you MUST have this in session (which seems more to be an agenda issue rather than a technical one), then you'll have to use a STATE SERVER. What that does is store all session in a preconfigured DATABASE. Among many things, the downside to this is that the user's session will get hydrated with the 30000 records on EACH request. This will result in further performance degradation.

    Here's another thing that you can do (and I've mentioned it before, explaining it more clearly). Have a secondary data store to which you store the results of your filtering. This can be sql server or it can be something like redis or raven or even an xml / json file. When you are currently storing the 30k records in session, store that in the secondary store instead. Now store the identifier for the info (could be redis key / sql key / flat filename) in Session. Now on subsequent requests, when you are planning to read from session, read the identifier from the session and read the actual data from the data store based on that identifier.  This will allow you to perform pretty much the same task (with a little extra work) without killing the server. Does that make sense?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 2:11 AM
  • User1779161005 posted

    I'm late to the conversation, but I've been trying to wean people of of session state for years.

    http://brockallen.com/2012/04/07/think-twice-about-using-session-state/

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 6:01 PM

All replies

  • User-1179452826 posted

    It shouldn't be "stopping" the events. But realistically, DON'T put that much data into session. Perhaps store the data in a datastore and put the id of the entry into session. Just because a feature is there doesn't mean you should abuse it. And no, it doesn't "have to be there" - there are many ways of achieving the same result.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 1:48 AM
  • User-1556678718 posted

    DON'T put that much data into session. Perhaps store the data in a datastore and put the id of the entry into session. Just because a feature is there doesn't mean you should abuse it. And no, it doesn't "have to be there" - there are many ways of achieving the same result.

    I need to have this much data into the session. This is filtered out of few milions of records, so it is only 30000, and it can't be less. about stopping the events, no event is starting, for all i get

    Internet Explorer cannot display the webpage

    Friday, August 24, 2012 2:00 AM
  • User-1179452826 posted

    Right...try to understand this - Session data is stored ON THE SERVER. By default, this is stored in SERVER RAM. If you want 30000 entries for each user stored in SERVER RAM, you will soon run into trouble. Your app pool will recycle KILLING the session ANYWAY. (This is most likely why you're getting the error). If you're convinced that you MUST have this in session (which seems more to be an agenda issue rather than a technical one), then you'll have to use a STATE SERVER. What that does is store all session in a preconfigured DATABASE. Among many things, the downside to this is that the user's session will get hydrated with the 30000 records on EACH request. This will result in further performance degradation.

    Here's another thing that you can do (and I've mentioned it before, explaining it more clearly). Have a secondary data store to which you store the results of your filtering. This can be sql server or it can be something like redis or raven or even an xml / json file. When you are currently storing the 30k records in session, store that in the secondary store instead. Now store the identifier for the info (could be redis key / sql key / flat filename) in Session. Now on subsequent requests, when you are planning to read from session, read the identifier from the session and read the actual data from the data store based on that identifier.  This will allow you to perform pretty much the same task (with a little extra work) without killing the server. Does that make sense?

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 2:11 AM
  • User1779161005 posted

    I'm late to the conversation, but I've been trying to wean people of of session state for years.

    http://brockallen.com/2012/04/07/think-twice-about-using-session-state/

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, August 24, 2012 6:01 PM