Session State lost in asp.net - solution explained.

[Brian Schloz]

Hello,

I just thought I'd share my particular situation regarding session
state periodically being "lost" in my asp.net app. I read with
interest all of the posts regarding lost session state (virus scanner,
modified assemblies/configs, etc.). The suggested solution of using a
'State Server' or 'SQL State Server' was not attractive to me given
the drawbacks: performance, objects must be serializable, no more
Session_End.

Perhaps the most helpful advice I ran across was to use Performance
Monitor (perfmon) to monitor various counters of the .NET processes.
So, I setup perfmon and added all sorts of counters. The two counters
that led to my solution were: Application Restarts and Compilations
Total. After a period of monitoring I noticed that 'Compilations
Total' would hit a threshold and kick off an Application Restart
(which in turn caused anyone in my app to lose their session state).
After careful review of the machine.config file, I found the culprit:

numRecompilesBeforeAppRestart="max number of recompilations before
appdomain is cycled" // Default: 15 recomplations

If I increase this number to say "9999", I never run into the lost
session state. However, I am concerned about this solution given by
the fact that the default value is so low (15 - why????). Unless
someone can point out the reason this may be a bad fix, I will happily
continue forward (my users are happy now too).

Brian Schloz
Lead Software Engineer
JHOB Technologies, LLC

[Cowboy \(Gregory A. Beamer\)]

The downside is you have to manually restart the app every once in awhile to
clear out memory. There is a known bug in 1.0 (see KB 319947).

In most cases, you should not have to dynamically recompile resources very
often. If your app recompiles on a regular basis, you have another problem:
perhaps a design problem, perhaps a resource problem.

One possibility, for example, is an app that writes values to web.config,
which will force a dynamic recompile. If this case, the correct design would
be to only store constants in the .config and other app values in either a
static object or some other form of cache.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

************************************************** **************************
****
Think Outside the Box!
************************************************** **************************
****
"Brian Schloz" <bschloz@hotmail.com> wrote in message
news:e35f6178.0307250702.6f6450dd@posting.google.c om...

> Hello,
>
> I just thought I'd share my particular situation regarding session
> state periodically being "lost" in my asp.net app. I read with
> interest all of the posts regarding lost session state (virus scanner,
> modified assemblies/configs, etc.). The suggested solution of using a
> 'State Server' or 'SQL State Server' was not attractive to me given
> the drawbacks: performance, objects must be serializable, no more
> Session_End.
>
> Perhaps the most helpful advice I ran across was to use Performance
> Monitor (perfmon) to monitor various counters of the .NET processes.
> So, I setup perfmon and added all sorts of counters. The two counters
> that led to my solution were: Application Restarts and Compilations
> Total. After a period of monitoring I noticed that 'Compilations
> Total' would hit a threshold and kick off an Application Restart
> (which in turn caused anyone in my app to lose their session state).
> After careful review of the machine.config file, I found the culprit:
>
> numRecompilesBeforeAppRestart="max number of recompilations before
> appdomain is cycled" // Default: 15 recomplations
>
> If I increase this number to say "9999", I never run into the lost
> session state. However, I am concerned about this solution given by
> the fact that the default value is so low (15 - why????). Unless
> someone can point out the reason this may be a bad fix, I will happily
> continue forward (my users are happy now too).
>
> Brian Schloz
> Lead Software Engineer
> JHOB Technologies, LLC

[Brian Schloz]

Update. I solved the second issue (Application Restart for no apparent
reason). It was the network backup. Evidently, SMB does *something*
with the file to cause the 'Accessed' bit to be updated and therefore a
NET application restart when the web.config and/or bin directories are
subjected to the backup process (note: the Archive bit remained
unchanged). I only noticed it when I turned on the Accessed column in
Explorer (right click on the heading and add 'Accessed' column). Since
it was happening when nobody was on the system (at night) I assumed it
was because the process was idle. Anyhow, I think slowly but surely I'm
getting there.

*** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
Don't just participate in USENET...get rewarded for it!