CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Grant Killian's Blog

No, this has nothing to do with beer -- but maybe it should?

Disappearing Session Objects

I guess this is my night to share .Net issues my students have uncovered . . . here's one I don't have an answer for . . .

The asp.net session objects (and cache objects) in her application are consistenly destroyed after a few page requests.  This only happens on this one particular machine (isn't it often that way?), so we immediately check the Session settings in Web.config and in IIS (session timeout property); everything checks out normally. 

The Cache object is an easy one . . . when a server is running low on resources, the Cache dictionary can be scavenged by the server; it's a “too few resources” thing.  All work with a Cache object should begin by testing for the presence of the item in the Cache; you never know when you may have to recreate an object that was stored in the Cache.  As an aside, check out this tip for a way to respond when an item is deleted from (it uses Delegates . . . a favorite topic of mine).

The Session object, however, is an odd one.  I haven't heard of Session objects being scavenged like Cache objects, but this was certainly looking that way -- although Task Manager doesn't show a heavy burden weighing on the machine.  The Session object would have get a new Session ID, so the server is discarding the old session and regenerating a completely new one.

Requests from computers other than the server would still manifest this Session problem -- so I eliminated the client browser configuration issue from consideration (thinking that, perhaps, the cookie that Session State relies on by default was being deleted or blocked by privacy software -- no luck there). 

So, while I'd like to share the solution to the student's dilemma, we haven't found one.  She is going to work on a different server with “normal“ behaviour or avoid session state while playing with .Net on that server.  I realize this isn't an acceptable solution for the “real“ world, but so far this problem has only manifested itself in the “unreal“ world of academic licensed server and application software -- and only one computer at that.

If anyone has any ideas I'm all ears!

Happy .Netting



Comments

Darrell said:

You can verify that the app is restarting by using the Performance admin tool and setting up an ASP.NET counter for Application Restarts. I think by default IIS will restart if it reaches something like 60% of server utilization, but not sure on the exact number though.
# December 1, 2003 3:50 PM

JosephCooney said:

I've also heard of virus scanners etc causing ASP.NET applications to re-start when they cause the HTTPRuntime to think that the web.config has been updated. There are lots of things that can cause an ASP.NET App to be reloaded. Here is some info: http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=232621
If the application ISN'T restarting then that is even more mysterious.
# December 1, 2003 4:58 PM

Chris said:

Did you check the event logs? Did you see anything out of the ordinary in them?
# December 2, 2003 3:31 AM

Vincent O' Keeffe said:

Not sure if this is any help but I was suffering the same weirdness where session was getting nuked at a particular point in the application. Turned out it was due to an unhandled System.Threading exception during a Reponse.Redirect. A try.. catch block around the offending statement meant everything stayed up and session was maintained.

May not be your student's scenario, but just thought I'd throw it in there.
# December 2, 2003 5:07 AM

Aaron Robson said:

I thought the session object (inproc) used the cache as its implementation... so if the cache can be trashed by low resources, wouldn't the Session object go too?
# December 2, 2003 10:00 AM

Catherine Bell said:

Your not going to believe this....or maybe you will. The problem was that I stored the Access database being used by the application in the \bin folder!!! After everything I've read and everything Grant taught me...{hangin' head in shame}

Thank you all for your suggestions. It was the performance logs that gave me the clue....many, many, many restarts....thanks again.
# December 2, 2003 3:44 PM

Grant said:

Interesting, the logic being the presence of the access database in /bin would cause an app restart whenever the db changed (like a change to web.config, only different). Using an MDB file means the ldb file gets created and so on . . . I'll have to post all the details once you share them with me.
# December 3, 2003 4:34 AM

Ravi Bajaj said:

Jesse Ezells Solution worked for me. Thanx for the help.
# July 7, 2004 4:28 AM

Percival Burger said:

I have the same problem, but with asp pages.
I can retrieve a table on page1 as many times as I like, and change the dropdown that submits page2 as many times as I like, but when I change the dropdown on page2 AFTER I retrieved the table on page1 (even just once), the SESSION mysteriously restarts (not the application). I have exactly the same pages on another machine that also runs IIS, but it doesn't happen there.
# July 28, 2004 3:35 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!