>Rick, thanks so much for the suggestions. Kevin said that mmDataSet was not marked as Serializable and that it has been corrected for the next release of MM.NET.
>
>However, you make some good points on the scalibility with SQLServer. Bob Archer referred me to a webcast from Microsoft (http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032250622&Culture=en-US). The presenter makes the case for always using InProc sessions and using a load balancer that enable "sticky sessions". Though the sessions will not be completely evenly distributed, the speed benefits evidently far outweigh the slight inbalance in a web farm scenario.

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 ---