Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

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

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Disappearing Session Objects

  1. Percival Burger says:

    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.

  2. Ravi Bajaj says:

    Jesse Ezells Solution worked for me. Thanx for the help.

  3. Grant says:

    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.

  4. Catherine Bell says:

    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.

  5. Aaron Robson says:

    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?

  6. Vincent O' Keeffe says:

    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.

  7. Chris says:

    Did you check the event logs? Did you see anything out of the ordinary in them?

  8. JosephCooney says:

    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.

  9. Darrell says:

    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.

  10. Jesse Ezell says:

    I have heard of this happening before. Most likely the app is restarting (IIS will recycle processes automatically). Try using a session state server instead of in proc (either the session state server that comes with ASP.NET or SQL server).

Leave a Reply