Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Session State - When to use and how to clean up? 1

Status
Not open for further replies.

keyser456

IS-IT--Management
Nov 21, 2003
73
US
As a former .NET windows applications programmer, I'm having a bit of a hard time in my transition to web programming. This stateless thing is killing me. Basically, I want to use anywhere from one to three different DataTables for each web page for this site. All the pages are working just fine, but they are all storing their DataTables to Session so that the data will be available during postbacks. For the life of me I can't figure out how I can clear out these items from Session state when the user goes to a different page. I see the page's Unload event, but that fires right after the page is rendered. I don't want to remove my datatables yet because I'll need that data in case of a postback. The site has a couple common .ascx controls that allow page navigation, so making sure the datatables are cleaned out just doesn't seem like it's possible. Am I just going about this wrong or what?
 
You can remove an item from session once you have finished using it e.g.
Code:
Session.Remove("myDataTable")
However, it may be that you didn't actually need to plce it in a session variable in the first place if you are only doing so to keep it's data during postbacks (data can be stored in the viewstate of the page).

Maybe if you explain exactly what you are doing, we may be able to offer some alternative ways of doing it that would avoid the need to saving to and removing session variables.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 
I'll just concentrate on one page for now. This page has 4 datagrids. During Page_Load and !Page.IsPostBack I'm retrieving the data that will be shown in these datagrids into DataTables. Because I'll be using this data during postbacks, I store all these tables to Session. The DataGrids are really just to show the data, when the user clicks on add/edit/delete the datagrids are hidden and an "editor" section is displayed.

Not all of the data in the datatables is going to be shown in the datagrids, but I want to be able to access this extra data. Instead of adding several Invisible columns to the datagrid that contain all the extra data I'm not using, I'm using just a couple hidden columns that give me the relevant IDs for the record in the datagrid that I'm editing and storing those to hidden controls on the page. On postback, I regrab the DataTables I stored to Session above and, depending on the data in the hidden controls, I do a DataView.RowFilter on the tables to find the record, and then fill in all the fields of the editor.

I guess most people just store all the data in the datagrid, regardless of whether they're using it there or not? That or maybe they're just making several trips to the db to get the same information they already had?
 
If you "know enough" to load the DataTables, to display the table, then you "know enough" to get the data from the original source on postback. You don't NEED to get the data from Session,ViewState, etc.

In other words, you maintain the data server-side, rather than client-side. The only "data" you need from the client is anything they've entered into a form.

Data is stored in a database. If you need to "re-use" data that you used previously, either retrieve it again, or store it on the server, perhaps in an XML file.

Thomas D. Greer
 
Hmm... I think that advice helps me quite a bit.

I guess I'm placing too much importance on making as few trips to the database as possible?

It just seems strange to me that I have to make another call to the database on basically every click. I'm used to getting a copy of the data from the datasource and then working with the disconnected copy.

Now I'm going to retrieve the data for displaying and only display the fields I need, and then retrieve a smaller subsection of the exact same data (unless it's been modified) again when I click to edit. It just feels wrong. :) I suppose I'll just have to get used to it. Thanks!
 
I sympathize. But connection pooling and caching lessens the impact. ASP.NET makes a valiant attempt to disguise the client-server nature of the web, but all the smoke-and-mirrors doesn't make it go away. The server does NOTHING until the client submits a request, and the client has to WAIT until the server generates a corresponding response. You have to balance the response-time/bandwidth issue against the database peformance issue. Usually, it's much faster just to retrieve the data you need, when you need it, each time you need it, than to pass bloated data-stores back-and-forth.

I've been accused, with some merit, of being an ASP.NET naysayer. So I'll give credit where it's due: the ADO.NET implementation is very good, and you can relegate a lot of work to the database and stored procedures, and with very little coding write your own database access class.


Thomas D. Greer
 
Again, tgreer is right to point out the issues of db performance against bandwidth/timings. He also hints at at some possible ways of reducing this.

From your original post, you said:
The site has a couple common .ascx controls that allow page navigation, so making sure the datatables are cleaned out just doesn't seem like it's possible.
After seeing your next post explaning what you are trying to do (which is why I'd asked for a bit of background to your needs), it would seem to be that this is where the idea of caching would come into play. The current .NET framework allows you to cache pages (and this can be based on variables submitted to the page as well) by using something like:
Code:
<%@ OutputCache Duration="30" VaryByParam="none" %>
You may be able to utilise this so that the navigation user controls are cached and therefore don't need subsequent trips to the database.

The next version of the framework is much improved in this area and allows you to cache certain parts of you page much easier.


____________________________________________________________

Need help finding an answer?

Try the Search Facility or read FAQ222-2244 on how to get better results.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top