View Single Post
  #8 (permalink)  
Old April 12th, 2004, 08:29 AM
Ron Howerton Ron Howerton is offline
Friend of Wrox
Points: 2,876, Level: 22
Points: 2,876, Level: 22 Points: 2,876, Level: 22 Points: 2,876, Level: 22
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Denver, CO, USA.
Posts: 428
Thanks: 57
Thanked 2 Times in 2 Posts
Default

[quote]Originally posted by Imar
 Hi Ron,

The logs you posted actually consists of two parts: a header and the actual page requests. The header (see below) can appear multiple times in the same log file, and is written every time the IIS process starts.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2004-04-08 13:11:28
#Fields: time c-ip cs-method cs-uri-stem sc-status

So, when you boot and request the first page in your site, restart IIS manually or when the IIS process is recycled, you'll see this header appear in your log file. If you see many headers for the same date, you're probably using process recycling. You can also see the date and time the process was started. If the date and time more or less matches the date and time your session values are lost, you probably found the cause of the problem. In Windows Server 2003, you'll find this setting on the Properties for the Application Pool your application is using. Can't remember where exactly it is locate on Windows 2000.

Ron replies:
Imar,

Thanks for the detailed explanation - this is better than anything else I've been able to find so far anywhere on the web. I've checked the log files and don't see any apparent regular restarts of IIS ocurring. To verify it, I tried restarting IIS and sure enough, I got another set of headers. Although I am seeing multiple headers in one or two log files, they don't appear to be consistently occurring at regular intervals, and more likely are associated with reboots to my development system for various reasons. I certainly don't see multiple ones coinciding with this particular problem, although that's difficult to say for certain because the time stamps on the log records are not recording the correct time (it appears to be off from the system clock by almost 6 hours - very strange). It almost appears as though the files are not complete, because I could swear I've made multiple calls over and over on some days trying to reproduce this problem and the log files don't seem to show that many requests, but it's hard to be sure with this time issue. Anyway, I can't find the Application Pool to check it's settings, but based on the fact that I'm not seeing multiple headers at regular intervals, this wouldn't appear to be the issue anyway.

Storing "the session variables in cookies instead of inproc" isn't really the way things work. A cookie is used to track the ID of the sessions, so when you visit another page in your application, IIS is able to hook up your request to the existing session object that holds the session values. This object always needs to be saved on the server. How this session object is stored is important. InProc means it's saved within the IIS process. StateServer uses a different stateserver, a process (a Windows Service) that can run on the same or another computer and that does not go down with IIS. The third alternative is to use a database, as Peter suggested.

I think you're best off using the StateServer setting as it will protect your session variables without the need to set up the state server functionality in SQL Server.

Ron replies:

Thanks also for this explanation. Session variables are a sort of black box to me - I just expect them to work and didn't think I'd need to know so much about their gory details. At this point I'm concerned about their reliability regardless of where they're stored, and as I've changed my code back to using encrypted querystrings, I'm reluctant to change back to session variables where ever they're stored without knowing with certainty that they'll work, as this will jsut put me further behind on this project. I think I'll just stick with a poor work around over something that just doesn't seem to work. Once I get done with this project, I'll probably rebuild the development box with the latest VS version, and maybe this'll just magically go away then.

Thanks again for your help with this.
Reply With Quote