sql server session in master page and in aspx page

I'm using SQL server session state.

If I'm using a master page that's calling a few variables stored in the session, and then again use the session later in the aspx code behind, does this trigger:

a) 2 datab开发者_Go百科ase reads, 1 during the master page process and a second one when the aspx runs.

b) 1 database read, the session is loaded during the master page process and persists during the life cycle of the page.

Thanks.

Master pages are user-controls attached to a page, and treated as such. As such, this question applies not just to Master Pages, but to all user controls, custom controls, and standard controls attached to a page.

SQL Servers stored session state is serialized/deserialized into/from the SQL Server on request. This is not a request of the variable but rather the HTTP request itself.

In the page lifecycle, the values are retrieved in the AcquireRequestState event, and pushed in the ReleaseRequesteState. These events are aspects ofthe HttpModule system, and as such are inherited by the Page class.

So, to answer your question, there is just a single call at the beginning of the page's life cycle (before INIT) to the SQL Server to get the entire set of session variables regardless of how many variables you have in Session State. Then at the end of the page's life cycle (and this is after RENDER & UNLOAD) there's a second database call to store the session state

The reads will result in only 1, the session object is recreated from the store at the beginning of the request.

When a page saves data to Session, the value is loaded into a made-to-measure dictionary class hosted by the HttpSessionState class. The contents of the dictionary is flushed to the state provider when the ongoing request completes. If the session state is empty because no data has been programmatically placed in the dictionary, no data is serialized to the storage medium and, more importantly, no slot is created in either the ASP.NET Cache, SQL Server, or NT state service to track the current session. This is done for performance reasons but has a key repercussion on the way in which the session ID is handled: A new session ID is generated for each request until some data is stored in the session dictionary. - see http://msdn.microsoft.com/en-us/library/aa479041.aspx for more details