After a user has initially established session with ASP.NET, with each subsequent HTTP request how much of StateServer session objects are immediately and automatically fetched and deserialized? For example:
Are ALL session objects fetched the moment the request is received and session re-established, or...
After session is re-established are session objects fetched and deserialized individually as each request to HttpContext.Session["..."] is made?
The answer has a HUGE impact on how I can use session. For example, if I have pre-fetched a significant amount of user data into session, and the StateServer session is completely deserialized upon each HTTP request, then I will experience a noticeable performance hit. If however the pre-fetched user data is only deserialized when I request specific session keys, then for me there is no worry.
UPDATE
After marking an answer to this question, I discovered that ASP.NET with AppFabric Server 1.1 has an option to have session restored on-demand rather than all-at-once. This is controlled by useBlobMode in your web.config.
Session loads all of the user Session information when the page is first loaded. It then persists the users Session information back to the store after the page is done processing.
You can get a better understanding via MSDN on custom state store implementations.
This is a major reason that you're supposed to use Session as rarely as possible because it is expensive to deal with (both in the transporting to and from the data store and the holding of the data in memory for the lifetime of the page request).
Related
I'm not a fan of using ASP.NET session state, but our application is using it at this time. We are using SQL Server mode for session state persistence. I'm considering caching authorization check results in the session state, but I worry about the performance of this approach. How exactly does SQL Server session state persistence work in .NET?
From what I can tell, all session data is stored in one database row, with the data itself stored in one column. My worry is that if our application does 12 different authorization checks in one request, and each result is stored immediately after received, that 12 different database requests would be made as those items are stored, which would nullify any network request reductions that I'm trying to accomplish.
Is each session state mutation accompanied by a synchronous database request, or are all session state changes persisted at one time during the ASP.NET request life cycle?
Sessions are persisted at the end of each ASP.NET request after the ReleaseRequestState application event - and not on session data change.
Which one more costilier View State or Session when a bulk data is stored. Why?
Depends on your point of view and usage, but generally session is cheaper all around.
For the client, session is nearly free. It only has to deal with keeping up with a session cookie (or the session id via the url if you configured for cookieless sessions). Viewstate pushes all the data to the client, in the text of the page source.
For the server, session and viewstate both have a cost. viewstate has to be serialized and deserialized and moved across the wire. Session is stored in memory (unless configured otherwise) but doesn't have to be manipulated. So session uses more storage in memory over a longer period of time, viewstate creates temporary memory use and higher cpu hits. So it depends on how much data, how often the client is communicating with the server, and which resources you want to conserve... though in general, with bulk data, session would win hands-down in almost all practical cases.
ViewState will cost bandwidth and make your pages heftier while the Session will cost memory on the server or some other server if out-of-proc is used.
Please anyone explain me the difference between ViewState,Application and Session of a Page ?
Quick one liners - if you want more detail, just ask
ViewState is the variable that holds the current state of the page, which is held in a hidden field in the page (used frequently)
ApplicationState is a variable you can store values in during the life off the application (may get cycled periodically, and without your knowledge) (used less-frequently)
Session is the variable you can write to that will persist from the moment they hit your site until they close the browser. (barring any timeouts). (used frequently)
A great article :
How to Choose From Viewstate, Session, Application, Cache, and Cookies
Some good discussion about the difference between Session and Viewstate : Session Vs ViewState
Session state is saved on the server.
Session state is usually cleared after a period of inactivity from the user.
Can be persisted in memory, which makes it a fast solution. Which means state cannot be shared in the Web Farm/Web Garden.
Can be persisted in a Database, useful for Web Farms / Web Gardens.
Is Cleared when the session dies - usually after 20min of inactivity.
ViewState is saved in the page.
The view state is posted on subsequent post back in a hidden field.
Is sent back and forth between the server and client, taking up bandwidth.
Has no expiration date.
Is useful in a Web Farm / Web Garden
SESSION Variables are stored on the server, can hold any type of data including references, they are similar to global variables in a windows application and use HTTP cookies to store a key with which to locate user's session variables.
VIEWSTATE Variables are stored in the browser (not as cookies) but in a hidden field in the browser. Also Viewstate can hold only string data or serializable objects.
When we use view state to design a web application it retains it's state consistently, in it's current position. If we use session then it does not retain it's state, so when we refresh the browser it starts from the initial page.
Does IIS create the session id when a request is received and where is that saved (client or server)?
How does server recognize that the request is coming from the same user/session?
The answer to your first question is Yes -- if sessions are used, and Both.
A cookie is a short bit of text passed back and forth between client and server with every request/response.
IIS generates a session id, saves it, and any associated data, and passes the in a cookie to the client (browser).
When the client makes another request, it sends the cookie, containing the sessionID back to the server. The server can then look at the cookie and find the session (and the associated data) which is saved on the server.
In ASP.net, there are multiple places for the session to be saved, but it's always within the server infrastructure.
The default is the memory of the IIS Process. This means: if you reset IIS (or the whole PC) or even just the application pool within IIS, all sessions are deleted, and the session data is lost forever. Also, if you have a LOT of sessions and store a lot of data in each session, the process will require a lot of memory, which can be a problem. This is called "In-Proc" Sessions.
The main alternative is a SQL Server Database. That way, sessions are kept even after a restart and it does not really matter how large each session is. The main downside is the added latency: Fetching data from a database is slower that the In-Proc solution of course.
There are also some other methods how to store sessions (including the option to write a completely new session provider), but the two common ones are "The Memory of the Server" and "A MS SQL Database".
I'm using ASP.NET, with session state stored out of process in SQL Server. When a page request begins, are the entire contents of a user's session retrieved from the DB, deserialized, and sent to the ASP.NET process in one fell swoop, or are individual objects transferred to the ASP.NET process only as needed?
Basically, I have a page that stores some large objects in session, and it's hard for my application to determine when the data can be disposed. If the data is only pulled out of the DB when it's used then there isn't an issue; if the entire session state is chunked to ASP.NET for each page request, I might have a performance issue.
It's all in one go. The session object is recreated from the store at the beginning of the request. It lets ASP.NET work the same way no matter what the underlying store is.
You can find the gory details here.