Viewstate vs Rereading XMLDocument
-
Hi I need advice on which way to proceed. I have two scenarios Case 1: I have an aspx page which reads from a Xml file using XmlDcoument object, process it and stores the data in a datatable. The datatable may contain from 10 to max 1000 rows depending on the Xml file. I am using couple of update panels and hence there are frequent postbacks expected. My question is which would be better performancewise : 1. Store the datatable in viewstate / Cache / Session OR 2, Read the data from Xml file and build the datatable during each postback. Pls note that the xml file is very big and the processing involves multiple loops before storing the data in the required format in the datatable. Case 2: Here is a datatable whose rows are created based on the user input during partialpostbacks. The data should be retained until the final submit button is pressed. What would be the best way to achieve it. Store the datatable in viewstate Or Cache Or Session or declaring it as static. Please note that both the datatables are just pagelevel and multiple users may access it. I want each user to have their own copy of the datatable. any guidance on which way to choose would be appreciated. thanks Kit.
-
Hi I need advice on which way to proceed. I have two scenarios Case 1: I have an aspx page which reads from a Xml file using XmlDcoument object, process it and stores the data in a datatable. The datatable may contain from 10 to max 1000 rows depending on the Xml file. I am using couple of update panels and hence there are frequent postbacks expected. My question is which would be better performancewise : 1. Store the datatable in viewstate / Cache / Session OR 2, Read the data from Xml file and build the datatable during each postback. Pls note that the xml file is very big and the processing involves multiple loops before storing the data in the required format in the datatable. Case 2: Here is a datatable whose rows are created based on the user input during partialpostbacks. The data should be retained until the final submit button is pressed. What would be the best way to achieve it. Store the datatable in viewstate Or Cache Or Session or declaring it as static. Please note that both the datatables are just pagelevel and multiple users may access it. I want each user to have their own copy of the datatable. any guidance on which way to choose would be appreciated. thanks Kit.
Well, you must first be aware of the differences of functionalities between session, asp Cache and viewstates. It is not only about memory. For example: You load your page. You store some data in ViewState["x"]. You load another page. You also store some data in ViewState["x"], but it is a different data. No problem will be caused, as ViewState is linked to the calling page. If you open a new web-browser in the same page (Control+N) as soon as you do anything different, each page (the old and the new) will have different view-states, so the old-page will not display the new data if you press F5, for example. Session. If you put information named "X" in session, every page will share the same information. If you update information X in one page, it will also change the X visible in another page, which may not be wanted. But, of course, it will not affect other users, as they will have other sessions. Asp Cache. The cached item will be shared among all users. This is rarelly what is needed. The biggest problem of ViewState is that it is sent to the client. So, many times reprocessing the item is better (faster) than sending it to the client and receiving it back. But, I must say I have a solution for this. Look at my article: Pfz.Caching - ViewIds instead of ViewStates[^] Using it, the view-state will works as always in terms of being exclusive to a page, a Control+N will not corrupt it, but it will be kept in the server memory and/or disk, without being sent to the client. Probably the easiest and faster solution considering general cases.
-
Well, you must first be aware of the differences of functionalities between session, asp Cache and viewstates. It is not only about memory. For example: You load your page. You store some data in ViewState["x"]. You load another page. You also store some data in ViewState["x"], but it is a different data. No problem will be caused, as ViewState is linked to the calling page. If you open a new web-browser in the same page (Control+N) as soon as you do anything different, each page (the old and the new) will have different view-states, so the old-page will not display the new data if you press F5, for example. Session. If you put information named "X" in session, every page will share the same information. If you update information X in one page, it will also change the X visible in another page, which may not be wanted. But, of course, it will not affect other users, as they will have other sessions. Asp Cache. The cached item will be shared among all users. This is rarelly what is needed. The biggest problem of ViewState is that it is sent to the client. So, many times reprocessing the item is better (faster) than sending it to the client and receiving it back. But, I must say I have a solution for this. Look at my article: Pfz.Caching - ViewIds instead of ViewStates[^] Using it, the view-state will works as always in terms of being exclusive to a page, a Control+N will not corrupt it, but it will be kept in the server memory and/or disk, without being sent to the client. Probably the easiest and faster solution considering general cases.
Thanks for the reply, Paulo. I think I should explain my situation a bit more in detail. I am working on the reporting stuff - that produces a chart. The datatable stores the different data entered by the user that should appear in the chart. For someother reasons there are a couple of partial postbacks before the chart is generated. I need to hold the user specifications until the actual chart is generated. I am really fine with the Ctrl+N problem ;P When the user presses Ctrl+N to open another instance of the same page, it might be like he wants to see two different formats of report. In that case I am glad if the viewstate values of old and new page remains different. thats what I exactly want. I could achieve this behaviour with viewstate and also by declaring the datatable as static at page level. eg
static DataTable dt1 = new DataTable();
Even with declaring dt1 as static, Ctrl+N does not affect the old page. Old and new page has their own copy of the dt1 which is what i want. But I wonder which is efficient and is there anyother better way of doing it. (Just to remind you that this datatable is used only in the single page)
-
Thanks for the reply, Paulo. I think I should explain my situation a bit more in detail. I am working on the reporting stuff - that produces a chart. The datatable stores the different data entered by the user that should appear in the chart. For someother reasons there are a couple of partial postbacks before the chart is generated. I need to hold the user specifications until the actual chart is generated. I am really fine with the Ctrl+N problem ;P When the user presses Ctrl+N to open another instance of the same page, it might be like he wants to see two different formats of report. In that case I am glad if the viewstate values of old and new page remains different. thats what I exactly want. I could achieve this behaviour with viewstate and also by declaring the datatable as static at page level. eg
static DataTable dt1 = new DataTable();
Even with declaring dt1 as static, Ctrl+N does not affect the old page. Old and new page has their own copy of the dt1 which is what i want. But I wonder which is efficient and is there anyother better way of doing it. (Just to remind you that this datatable is used only in the single page)
The different copies are only achieved with ViewState. Using session or cache, except that you give different names, will not achieve different copies. That's why I say you must use ViewState. The only problem with normal viewstate is that it is sent to the client and so, if the data is large, it could make the page load really slowly. That's why I talked about my ViewState solution. So, go for the ViewState.
-
The different copies are only achieved with ViewState. Using session or cache, except that you give different names, will not achieve different copies. That's why I say you must use ViewState. The only problem with normal viewstate is that it is sent to the client and so, if the data is large, it could make the page load really slowly. That's why I talked about my ViewState solution. So, go for the ViewState.
Many thanks for the reply Paulo. But I am able to reproduce the behaviour by declaring the datatable as static at page level. I have always thought that a single copy of the static variable is shared by all the users. I guess i should start a new thread on this. anyways, many thanks for your reply and the amazing article.
-
Many thanks for the reply Paulo. But I am able to reproduce the behaviour by declaring the datatable as static at page level. I have always thought that a single copy of the static variable is shared by all the users. I guess i should start a new thread on this. anyways, many thanks for your reply and the amazing article.
Each static variable is unique for the entire application. All users, sessions and thread will share the same value. If the variable is marked with ThreadStatic, then it is unique for the thread but, still, for that thread any object (or page) referencing it will reference the same value (as one thread can process many page requests)