Reply to: ASP.NET, clear session variable when leaving page

[mcquiggd]

Might well do when I have the time... its in VB.Net mind. Might port a generic version to C# as of course it is the property of my client...

And its part of a complete framework of Custom Web Controls, base classes, Custome User Controls, hosts for dynically creating wizard-style interfaces based on XML meta data etc... it not an approach to a single page that needs to clear Session state when someone goes elsewhere....

[scotspine]

"Regarding ViewState -- that's for windows forms type functionality - NOT for general web use" - that's a curious comment!

been using lhotka [although decreasingly], since middle/late nineties. he must have breathed a sigh of relief when microsoft came up with the .not model and put an end to his attempts to force stateful objects into a web environment. overnight, they became the de facto standard. and his expert c# bus. objects shows a more balanced approach to the matter.
but the original post referred to a dataview and so i assumed that datasets were implicit in his design.

but come on mcgd - you are desparate to show us some of your stuff. post up your solution to this trivial problem...i'd be keen to see it, esp after having largely dumped base class/inheritance a couple of years ago in the web environment. i understand that .not2 might do a better job of it.

[ASB]

Aye I use Lhotka's approach albeit using it somewhat before I was aware of his work. On that matter, I am selling Lhotka's Expert C# business objects here if anyone is interested btw:

http://cgi.ebay.co.uk/ws/eBayISAPI.d...tem=9704256289

This is one book that is NOT toilet paper.

Regarding ViewState -- that's for windows forms type functionality - NOT for general web use.

What a shameless plug. Though I have put a bid on.

[mcquiggd]

Agreed - I never use DataSets. Custom business objects offer a much more OO aproach and can be easily generated by a variety of template based code generators. I like Rockford Lhotkas approach:

http://www.lhotka.net

ViewState is potentially very dodgy if you have a variety of connection speeds bewteen you and your users.... its a shame its often required for events but I tend to write custom controls (especially DataGrids) that automatically turn off viewstate for the individual Controls created by the grid (absolutley dozens of em) but still supports ItemCommand events and Custom Paging, which is all you really need. Output caching, data caching etc all help where appropriate.

The pages served by the current application I have written the framework for are typically 12-14k including images and viewstate. a 20 minute session timeout means even if they dissapear off to visit eBay at lunchtime the application still scales. Ram for a web server in a farm is cheap. The database is invariably the bottleneck unless it is well configured and maintained.

[DimPrawn]

Would not work for when the user navigates away to another site though.

[ASB]

What would be wrong with clearing it in Global_AcquireRequestState when the request is for a page it is not required on ?

[mcquiggd]

As an aside I seem to remember you can place ViewState in memory / database / file on the server - create a custom Grid and ovveride the specific event that saves the viewstate and handle accordingly.

Dont know if that really solves the problem though

[DimPrawn]

Watch your page size mind if your users are using dialup.

Other than that ViewState is a good solution in that the burden of state management is distributed amongst the clients and works well on server farms, but can slow the site as all that ViewState has to be uploaded to the webserver on every postback, and most up links are low bandwidth and hence slow.

[Jakes Daddy]

Thank you very much scotspine - works a charm

[scotspine]

set up something like:


protected DataSet MyDataSet
{
get
{
if(ViewState["MyDataSet"] == null)
{
return null;
}
else
{
return (DataSet)ViewState["MyDataSet"];
}
}
set
{
ViewState["MyDataSet"] = value;
}
}



pass your dataset into thiis on page load and use it thereafter for paging. test by shutting down sql server while paging...

[Jakes Daddy]

don't think you want to use session for that. use a protected member var which encaps viewstate...

Thanks for all the comments - I like the sound of this idea. I can see that the datagrid is in the viewstate (by toggling EnableViewState of my DataGrid, then view resultant HTML source, I can see the hidden field __VIEWSTATE has a lot more data when the datagrid's EnableViewState is set to True)
So, how do I capture the datagrids DataSource from the viewstate ? Which event do I need to write this into ?

Sorry if these are basic .NET questions; but 'basic' describes my level of understanding and experience at the moment

Cheers

Nathan

[mcquiggd]

It is definitely possible - ive recently written a .Net 1.1 application framework for a project that allows for mostly wizard style interfaces that amass a large amount of data into Session, often jumping into and back from sub wizards, and sometimes standalone pages that place data in Session.

Obviously there needed to be a way to tidy up data that was no longer required, as soon as possible....

However my solution to this might be overkill for you if you only require it for a single page...

Hint: It includes an 'IWorkflow' interface implemented by a base class that all my pages inherit from, a Property that specifies where in memory data should be stored (in a Hashtable), a test to see if that data is no longer required, LinkButtons and Server.Transfer. If you cast the HttpContext.Current.Handler to IWorkflow and it has a state of 'standalone' (the default), the base page does a Session.Remove (keyName). Otherwise, it has been passed via a Server.Transfer and the Properties of IWorkflow are persisted as long as the user stays within the context of a 'workflow' situation. As soon as they hit a page without a Server.Transfer being executed, the IWorkflow Property is set to standalone - the next time they request ANY page, the area of session previously used to collect data is removed.

This is in conjunction with Custom Web Controls that persist data to Session rather than ViewState, and do so automatically triggered by 'SelectedIndexChanged' type events, and detecting where to persist their state based on the location specified by the base page.

It suits the architecture, number of users, and requirements for being able to navigate through a large number of potential routes through the application before persisting data, and automatically tidies up after itself. The developers now just add a new project item based on my 3 templates, and make calls to an API to say 'StartSubSession'. They dont have to do anything to clear that up once they have finished with it.

[DimPrawn]

Well firstly I never really use in proc session state. It kills scalability and it gives problems with server farms.

So with SQL Server state sessions, I don't care about old session data, it gets cleared down by a SQL Agent job and consumes no RAM.

If I were storing data in proc session, I would only store a few bytes , not a whole data view.

[scotspine]

Session.Remove["keyname"]

or

Session.RemoveAll() to clear all session data

... but what event would you use to run that?

[DimPrawn]

Session.Remove["keyname"]

or

Session.RemoveAll() to clear all session data