Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Can someone give me a good reason why ViewState isn’t stored on the server by default?
Why not send a small session token in place of ViewState, which can then be mapped to whatever ViewState info is needed on the server, to prevent the whole ViewState being posted back and forwards multiple times.
Am I missing something?
There are a number of issues with storing the ViewState in memory.
If the application recycles, the VS for all anyone using the application is lost.
It increases the memory consumption of the application. This isn’t an issue if there are only a few apps hosted on a server; but there are cases when there could be many websites hosted on one box.
Scalability; the more active the application, the more VS needs to be stored. And you can’t assume 1-1 (1 user – 1 VS). A user can have multiple tabs open, can go back, leave tabs inactive, etc… which leads to:
How long do you store VS? Keeping the data encoded on the page ensures that it’ll still be there if the user leaves the site open for a while.
What happens if you’re hosted on a web farm. We can’t guarantee that the user will hit the same machine on each request.
That being said, there are a few solutions:
Memcached-Viewstate – stores the VS in distributed memory using Memcache. This isn’t ideal – if a server goes down the VS for anyone who had the VS stored to that server is lost, but will allow for application pools to reset without issue.
SQL-Viewstate – stores the VS in a SQL database. This adds a least 1 DB read and 1 DB write per request. Again, not ideal, but if the VS is getting unmanagable getting and setting the VS from the database is faster than sending and recieving it over HTTP.
Filesystem-Viewstate – stores the VS in the filesystem. It’s less expensive than the SQL connection but would require a file server to work in a distributed environment.