CODEWITHSUNDEEP
asp.netsessionviewstate
Korey
Korey

Reputation: 999

Using session like ViewState

I am fixing an ASP.NET application that makes heavy use of session to track per-page data. One of the problems is that the session bleeds between pages.

ViewState would be a better solution, except:

So I want to:

Is there a good way to expire partial session data?

Upvotes: 1

Views: 1484

Answers (3)

Darthg8r
Darthg8r

Reputation: 12675

The following temporary storage locations are available:

  1. Session. This follows a user around and uses a cookie. It can be configured to use a URL param to retrieve. Session can also be configured to be stored in process(inproc) on the web server, in SQL Server, or in a state server. InProc can store any data type, but the others require the type to be serializable.
  2. Cache. Data stored in Cache is available to be used by any user in an session. It works similar to session, as the objects are retrievable via a key. One of the nicer features of cache is that you can control how long things are stored, and you can consume event when they expire. You can store anything here, but you may run into issues with using it in a webfarm.
  3. HttpContext. This is scoped to the current request. Remember, requests can be webservice calls, calls to get webpages to get HTML, or calls to a service that returns images. Anything can be stored here.
  4. ViewState. View state is scoped to a page. Must be serializable.

You may want to examine cache. If you're using a webfarm, it won't work, but you could use a GUID of some sort as the key that you map back to a session.

Upvotes: 2

AaronSieb
AaronSieb

Reputation: 8266

I would probably do it this way:

  1. Create an object to store the state information you want to be page specific. If different pages need different information, create multiple classes.
  2. Store this object in a single session key: Session["PageSpecific"]; for example.
  3. Create a class which inherits from System.Web.UI.Page.
  4. In the OnLoad event of the base class, clear the session key if the the page is not performing a postback.
  5. Create and call an overloadable method to populate the session object.
  6. Instead of inheriting from System.Web.UI.Page in each of your pages, inherit from your new base class.

Something like this (warning: air code. May contain syntax errors):

public class PageBase
    : System.Web.UI.Page
{
    protected overrides OnInit(System.EventArgs e) {
        base.OnInit(e);

        if(!this.IsPostBack) {
            Guid requestToken = System.Guid.NewGuid();
            ViewState["RequestToken"] = requestToken;

            Session["PageSpecific" & requestToken.ToString()] = InitializePageSpecificState();
        }
    }

    protected virtual object InitializePageSpecificState() {
        return new GenericPageState();
    }

    //You can use generics to strongly type this, if you want to.
    protected object PageSpecificState {
        get {
            return Session["PageSpecific" & ViewState["RequestToken"].ToString()];
        }
    }
}

Upvotes: 1

Kurt S
Kurt S

Reputation: 21357

Perhaps on each page !IsPostBack or through a base page you could null out all references to session data not pertaining to that page. This would "expire" the data each time the user goes to another page in the site.

If the user leaves the site or goes in-active, there's not much you can do until the session expires, but in this scenario there would only be one page worth of session data per user.

Upvotes: 0

Related Questions