Why should or shouldn't I store a Dataset, Datatable, etc as a session variable in an ASP.NET page?

Question

I am working on a web application that is consuming a Dataset returned by a web service.

As the application is running I store that Dataset as a session variable to be used over and over again as the user navigates to the different pages that will edit the tables within the dataset.

The idea was the user will only have to wait for the data once when the application loads then the application would use the session variable until the user saves the changes they made, when that happens it would pass the edited tables to the service to update the database.

Is there problems with this design and the storage of the Dataset and Datatables as a session variable? Pros and Cons let me know.

Answer 1

The only pro is:

• It's faster than repeatedly going to your database. That said, Enterprise databases do enough caching that you don't often need to.

The cons are legion but the main three would be:

• If data is changed from another Session (say an admin user), your user's Session doesn't know
• Memory allocation can be a serious issue very quickly (although this can be alleviated by using Cache instead of Session and keying on Session ID)
• If you ever move to a server farm, you're going to have to rethink your entire design, quite possibly using the DB to store Session Data - then your efficiency argument is going to look a little weak

[Edit] As others have pointed out, there is also a problem with saving anything in Session or Cache (or to a lesser extent Application) without persisting it somewhere more permanent as well. If a Session expires, or even resets itself (I have seen hardware configurations that cause the Session to begin and end with every request. Though it retains the Session ID, any data stored in Session objects is lost. If the Application is restarted for whatever reason, all of the Session, Cache and Application objects are cleared down. Cache objects can clear theselves at any time, just because the environment decides it wants that memory space for something else.

In summary: This is not the way to go.

If you need the user to be able to make changes and then hit Save to persist them, keep a separate set of State tables that detail the changes that should be made to the main tables when the user hits Save. Store a cookie on the client with a key which expires a long way into the future; use that cookie to match your State data to the User.