Reputation: 5459
I have a page on which data table is created programmatically if the data is not there in the database tables. I have to use this data table in many events during postbacks. The data table may contain hundreds of records and there may be multiple users accessing the same page(Of course with different data source for each user). I am storing the data table in view state but I am afraid that this practice will make the page heavier. Is there any other way to preserve the data table across postbacks.The code is very long so I can not copy and past it here.
Using session will again make the whole application heavier...So is it better choice over viewstate??
Upvotes: 2
Views: 1376
Reputation: 49215
If data is user specific then you can use Session. However, in case of out of process session state, you may have issues because all that data needs to be marshaled back & forth from session store.
Otherwise Cache is a good option but you need to choose cache period and expiration policy on typical usage scenarios (and also need to handle cache expiry scenario gracefully).
Yet another option is to push the data into temp file - however, in such case, you need to manage file clean up etc.
Upvotes: 0
Reputation: 3318
In your case the view state can get very big and will hurt page load performance. IMHO the best thing would be to revise the way your are handling the post back events.
For a quick fix I usually store the View State on the server. Refer to this page to read about it... http://aspguy.wordpress.com/2008/07/09/reducing-the-page-size-by-storing-viewstate-on-server/
Upvotes: 1
Reputation: 3107
You should use Session
. Also it's possible to use Application
or Cache
but you'll have to generate and store a unique key on your page to negate possible interferention between requests from different users.
Upvotes: 2
Reputation: 5594
If the data table is different for each user, you should use Session
or you could use Cache
, assumed to make a different Cache object for each user.
But if the data table is very big probably is not a good idea to store it in memory instead of direct db access.
Upvotes: 0