Bonnie,

Interesting article. It doesn't actually address what the performance cost would be using SQL Server to store state. I had an interesting conversation just a few weeks ago at TechEd with some members of the SQL Server team and other industry experts about this. There definitely is a consensus to only use SQL Server if the needs of the application demand it. Otherwise, using state server is considered best practice.

>Cathi (and David),
>
>>>Storing session state in SQL Server is the slowest of the three alternatives.
>
>Here's an article I read a year ago that seemed to indicate to me that the SQL Server alternative was not all that slow. Page 4 of this article has the relevant info:
>
>http://www.fawcette.com/vsm/2003_10/magazine/columns/aspnet/
>
>~~Bonnie
>
>
>
>
>>Hi David,
>>
>>Storing session state in SQL Server is the slowest of the three alternatives. Another approach is to use a State Server that is dedicated to storing state. It will give you the ability to scale your site to more than one web server like SQL Server does but will also give you better performance since the data is stored in memory on that machine and no data connections are necessary. You would need to text with the different scenarios to find out what works best given the needs of your application.
>>
>>Another thing to keep in mind is that the architectural design of the application, to need to store large amount of information in state, might need to be addressed. Applications should be designed in a way to minimize the state that is stored to allow better performance and scalability.
>>
>>>I have read on MSDN and other places that the size of data stored in the Session should be limited because the data is stored for every user. Does this only apply to Session data that is kept in webserver memory or the state server app of does it also apply to Session data stored in a SQL database?
>>>
>>>I have large data sets and complex objects that I would like to persist. Is there any reason that Session data stored in a SQL database needs to be kept small?
>>>
>>>If I use a SQL database to store session data, my Session data would represent only a tiny subset of my entire database, so I would think it would be a lot faster and more more efficient that redundant queries on my main database and subsequent object recreation. The Session database would serve to cache the collected data I am using.
>>>
>>>Am I overlooking something? I would appreciate input from anyone with experience with Sessions stored in an SQL database.
>>>
>>>Thanks.