Rick,

Thanks for the feedback. I'm not really moving a lot of data into sessions. I'll have to study and experiment with this more.

Regards,
Carl.




>I personally think that that advice is severely misguided mainly because InProc sessions are very vulnerable to restarts. Not just from the application, but even from the OS - IIS 6 automatically cycles Web Site instances for examples and can recycle on signs of high load or errors occuring in ASP.Net. InProc will lose sessions for each of these occasions, which is unacceptable for any serious application, especially if it's busy enough to require load balancing in the first place.
>
>Unless you're pushing tons of data into the Session object (at which point you're paying for the network hit with shared sessions) this Session hits should make up very little of your application's processing. Even if you run local Sessions I would suggest usnig the StateServer rather than InProc sessions because of the volatility, but in a Web Farm environment I think this wouldn't make sense either because of the affinity requirement it would impose on the load balancer. And the 'sticky' setup falls apart very quickly if you need to use SSL on one of the load balanced machines but not all of them (as is common in those scenarios).
>
>Bad idea all around, IMHO...
>
>StateServer is somewhat more efficient than SQL Server Sessions too because it's optimized for the Hashtable like storage the Session uses.
>
>
>Regards,
>
>+++ Rick ---