Losing Session variables/state?

I'm having regular issues with the ASP.NET 2.0 Sessions. The session variables work fine for the most part. I found, downloaded and installed a Session timeout control which is intended to resend the user to the login page when the session timeout is reached. This does work but I'm not sure how well. The control is installed on various Master Pages.

 The problem is that from time to time I get an Object reference not set to an instance of an object error:

if (DetailsView1.CurrentMode == DetailsViewMode.ReadOnly)
{
   string session = Session["client_id"].ToString();
   DetailsView1.Fields[5].Visible = false;
}

On this page, the italicised line is the one that brings up the error. The only thing is that I'm not sure if the sessions are ending when they should be.

It seems to be ending sessions too soon at times. Anyone have any idea how to fix this?

0
Tickled_Pink
11/17/2006 12:06:27 AM
asp.net.state-management 8807 articles. 0 followers. Follow

3 Replies
642 Views

Similar Articles

[PageSpeed] 38

Its an issue that really should be "advertised" more, for lack of better word, because it is that way by design, and it misleads people. By default, the Session is in process, which means anytime the application recycles itself (which happens VERY regularly, to get back used up memory, etc... ), you lose all session.

The solution, is to use State Server or SQL Server Session state, so that the session is stored outside of the main process, thus when it recycles, you don't lose the session. The default session (In proc, or in process), is more of a user-specific cache than anything: fast but volatile. Its rarely what one needs though.

http://www.samspublishing.com/articles/article.asp?p=30026&seqNum=3&rl=1

This should get you started. 

0
shados
11/17/2006 2:03:18 AM

That's excellent. Just what I need. Thanks.

 Just wondering as well: how can I implement a Logout feature on my pages if I use the external session server?

0
Tickled_Pink
11/17/2006 1:08:22 PM

Exact same way you normally would. Session.Abadon, FormAuthentication.Signout, etc, depending on what you're doing. The session can still timeout (as specified in your web config), and so on.

The -only- difference, is #1 You won't lose session -randomly-, only when it timeouts specificaly, or you programmatically get rid of it, and #2 you can only store serialisable objects (all primitive types work too). There is also a slight performance overhead, but that tends to be made up since it scales better.

So really, except that you won't lose session at random, nothing changes :)

0
shados
11/17/2006 9:24:57 PM
Reply: