<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://msmvps.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Serialized In-Process ASP.NET Session State Store</title><link>http://msmvps.com/blogs/paulomorgado/archive/2008/08/04/serialized-in-process-asp-net-session-state-store.aspx</link><description>ASP.NET provides out of the box three session state stores: Provider Description InProc Session state is stored in the ASP.NET cache. SQLServer Session state is stored out-of-process in an SQL Server database. StateServer Session state is stored out-of</description><dc:language>en</dc:language><generator>CommunityServer 2008.5 SP2 (Build: 40407.4157)</generator><item><title>re: Serialized In-Process ASP.NET Session State Store</title><link>http://msmvps.com/blogs/paulomorgado/archive/2008/08/04/serialized-in-process-asp-net-session-state-store.aspx#1643365</link><pubDate>Mon, 04 Aug 2008 22:59:01 GMT</pubDate><guid isPermaLink="false">d67277c4-116b-43f1-b688-e9ef184ea916:1643365</guid><dc:creator>Paulo Morgado</dc:creator><description>&lt;p&gt;I mostly agree with you, Pål, but…&lt;/p&gt;
&lt;p&gt;This is a step closer to the use of SQL Server in production environments. Probably as closer as using SQL Server Express or SQL Server Developer Edition. How many developers stress the session state database to simulate the production environment?&lt;/p&gt;
&lt;p&gt;All the stuff that you put in the session state needs serialization. I think that what you meant was that only primitive types should be put in the session state. This is a good practice in theory. If you only put primitive types in the session state you won’t have deserialization problems when a partial update to the application happens and the type of an item in the session state has changed. Also avoids throwing large objects into the session state.&lt;/p&gt;
&lt;p&gt;On the other hand, in the real world, sometimes you save stuff in the session state because it’s expensive to obtain and doesn’t change throughout the duration of the session. Why have another transitory persistence system?&lt;/p&gt;
&lt;p&gt;If you are building composite applications, you might be a module developer and your module might be used in a big application running on a big web farm or a small application running on a single server. Why should you need a SQL Server for such a small application? But the provided InProc provider just doesn’t work the same way as the SQLServer or StateServer ones.&lt;/p&gt;
&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://msmvps.com/aggbug.aspx?PostID=1643365" width="1" height="1"&gt;</description></item><item><title>re: Serialized In-Process ASP.NET Session State Store</title><link>http://msmvps.com/blogs/paulomorgado/archive/2008/08/04/serialized-in-process-asp-net-session-state-store.aspx#1643288</link><pubDate>Mon, 04 Aug 2008 12:48:15 GMT</pubDate><guid isPermaLink="false">d67277c4-116b-43f1-b688-e9ef184ea916:1643288</guid><dc:creator>Pål A.</dc:creator><description>&lt;p&gt;A cool project, but I cannot really see the need. Isn&amp;#39;t it much better to have your developers use the SQLServer provider instead? SQL Server Express is free and uses little extra resouces on your developers machines. The more similar the development system is to the production system the better.&lt;/p&gt;
&lt;p&gt;Also, putting stuff in session that requires serialization is not a good idea. As little as possible should be in session, and if you really require to use session, only add sinple types and integers, strings etc. &lt;/p&gt;
&lt;p&gt;If you feel the need to store complex structures and linked objects then you need to retake that ASP.NET programming class :)&lt;/p&gt;
&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://msmvps.com/aggbug.aspx?PostID=1643288" width="1" height="1"&gt;</description></item></channel></rss>