Skip to main content

70-562 Configuring State


CONFIGURING SESSION STATE

Look for the SessionState element in the web.config file.
StateServer can be used for a dedicated state server, a sql database can also be used, cookieless session state, and customcookie name, regenerating expired session ids, the timeout for the session with a default of 20 minutes.

This element wont be found by default in the default web.config files and web.config files, they use the default and are added manualy to override the defaults.

The "mode" attribute, can be Off if session state is not used, InProc is the default and sessions are lost when the server is reset, it's the oldest and performs the fastest since its' in Memory. SessionState is hosted by a windows service installed with the asp.net framework then it is stored in mem on that machine. SQLServer requires sql and a script provided by asp.net to configure it to store state. Custom is by implementing the SessionSTateStoreProvider class.

Advantage of StateServer and SQLServer mode is use for Web Farms. But there is an extra network hop involved, even if it's near by, it will add lag as the information is transfered between the machine, tradeoff between reliable scalable solution and performance. When InProc, a simple config change will restart the pool and loose the session. When switching to state server, objects not serializable will not be stored, they need to be serialized to be stored, for example the dataview object is not serializable, and can actualy throw an exception preventing all session state persistance. In order to be serializable, the object must implementthe ISerializable interface. It can still be stored InProc even if it's not serializable, and for custom classes, just need ot make them serializable and implement the ISerializable interface. One way to bypass the dataview limitation is to call the ToDataTable method of hte dataview, or use the dataview property of the table, or the datatable property of the view.


USING COOKIELESS SESSIONS
Set this by Cookieless to something else to UseCookies, this will make long urls with the ID in it.
The UseUri option wil put the session ID within the URL and use no cookies at all.
The UseDeviceProfile if the browser doesnt accept cookies, asp.net will automatically put the Session ID in the URL.

The AutoDetect, asp.net checks the http header to see if the cookie exists, otherwise it uses url.
Caution, if cookieless sessions are used, make sure to use relative URLs not absolute, if absoluted, use the Response.ApplyAppPathModifier method.


APPLICATION LEVEL STATE
Application level state applies to all session, for example storing the number of started sessions; this object is sharedacross all sessions. For example Application["ActiveSessions"] = 0; to avoid conflics when data is modified simultaneously,this object needs to be locked during incrementation, Application.Lock(); /*increment session counter*/ Application.Unlock().Note that this can prevent the session_end event to fire when expected. Note: "Out of process" storage is not supportedfor the

Application object. Application object is simular to global variables and usualy better solutions can be found fromViewState, SessionState or Caching since caching has vastly superior memory management.










Comments

Popular posts from this blog

React JS Patterns

React JS is always evolving, and evolving quickly. These evolutions can be very significant ones, for example, the addition of hooks. React has a lot of code patterns, often these patterns are motivated by the DRY and/or the open-close principle. These patterns sometimes come in to replace a previous one, yet the previous ones still stays in use, as a consequence, the list of patterns keep growing. The goal of the next few posts will be to list the patterns commonly used in React JS developpement. Some patterns are more specific to JSX and I will start with these, and maybe add patterns specific to Redux.

Rxjs Forkjoin vs Zip

These Rxjs combination operators are handy to make Rest calls in parallel and combine their results. Both take n observables and will return the results, with the difference that forkJoin will complete even if one of the nested observables errors of completes.

Object.create vs. Object.Assign

The two functions return a new Object but with a difference. Object.assign will go through an enumerable and copy it's properties. Object.create will create a new empty object but link it's proto chain to the old object. One way to view this is with JSON.stringify(newCreatedObject) this would return an empty object, since all the properties are not part of the object's own properties, but inherited through prototype inheritance. In both case, the advantage is it allows to extended existing objects without modifying the original. This is particularly important when receiving arguments from a caller, in this case it's better to use these methods instead of modifying the caller's object since he might have planned to use it again later, expecting it to be in it's original state.