In-process Mode in asp.net
In-process mode simply means using ASP.NET session state in a similar manner to classic ASP session state. That is, session state is managed in process and if the process is re-cycled, state is lost. Given the new settings that ASP.NET provides, you might wonder why you would ever use this mode. The reasoning is quite simple: performance. The performance of session state, e.g. the time it takes to read from and write to the session state dictionary, will be much faster when the memory read to and from is in process, as cross-process calls add overhead when data is marshaled back and forth or possibly read from SQL Server.
In-process mode is the default setting for ASP.NET. When this setting is used, the only other session config.web settings used are cookieless and timeout.
If we call SessionState.aspx, set a session state value, and stop and start the ASP.NET process (iisreset), the value set before the process was cycled will be lost.
asp.net session configuration
Below is a sample config.web file used to configure the session state settings for an ASP.NET application:
cookieless="false"
timeout="20"
sqlconnectionstring="data source=127.0.0.1;user id=
server="127.0.0.1"
port="42424"
/>
The settings above are used to configure ASP.NET session state. Let's look at each in more detail and cover the various uses afterward.
* Mode. The mode setting supports three options: inproc, sqlserver, and stateserver. As stated earlier, ASP.NET supports two modes: in process and out of process. There are also two options for out-of-process state management: memory based (stateserver), and SQL Server based (sqlserver). We'll discuss implementing these options shortly.
* Cookieless. The cookieless option for ASP.NET is configured with this simple Boolean setting.
* Timeout. This option controls the length of time a session is considered valid. The session timeout is a sliding value; on each request the timeout period is set to the current time plus the timeout value
* Sqlconnectionstring. The sqlconnectionstring identifies the database connection string that names the database used for mode sqlserver.
* Server. In the out-of-process mode stateserver, it names the server that is running the required Windows NT service: ASPState.
* Port. The port setting, which accompanies the server setting, identifies the port number that corresponds to the server setting for mode stateserver.
A Quick Overview of the ObjectContext in .NET
When working with the Entity Framework, the core class that you must use is the ObjectContext. This is the object that does all interaction with the database. It manages your database connection and handles all reads and writes as well as takes care of change tracking. It is probably the singular most important object when working with the Entity Framework but is also probably the most abused. The subject of the ObjectContext is a topic for an entire article on its own, but there are a few key things that will help keep you from running into trouble.
Because the ObjectContext does change tracking it is the source of most weird issues that people encounter when using the Entity Framework. Those new to ORM tools may not realize what is actually happening when change tracking is used. The Entity Framework makes it really easy to query objects, change them and then save them back to the database without you having to worry about insert order and writing update statements. The ObjectContext is smart enough to know what order things need to be done and generates SQL to make sure that all operations get completed as quickly as possible. The very nature of how change tracking works, however, is what can trip up developers.
When you query an object with the ObjectContext, information about the object is stored in the ObjectContext state manager. Reverences are held in memory so that when you make a change to the object, the ObjectContext has a reference point to know what needs to be changed. If you query a lot of objects, a lot of objects will be held in the state manager until the context is disposed. The ObjectContext implements IDisposable to make the process of cleaning up more straightforward. The problems start happening when you have too many objects in the context at one time. When you call SaveChanges() on the ObjectContext, it will look at all of the objects in the state manager and decide what needs to be done to them. As you can imagine, having more objects in the state manager will simply cause more resources to be used. If you have objects there you are currently not using, you are wasting memory and CPU cycles. There is no hard and fast rule on how many objects can be on the context at any given time but my recommendation is to keep as small as possible.
ASP.NET Cookies Overview
A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site.
For example, if a user requests a page from your site and your application sends not just a page, but also a cookie containing the date and time, when the user's browser gets the page, the browser also gets the cookie, which it stores in a folder on the user's hard disk.
Later, if user requests a page from your site again, when the user enters the URL the browser looks on the local hard disk for a cookie associated with the URL. If the cookie exists, the browser sends the cookie to your site along with the page request. Your application can then determine the date and time that the user last visited the site. You might use the information to display a message to the user or check an expiration date.
Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user's browser as well; the browser stores all the cookies separately.
Cookies help Web sites store information about visitors. More generally, cookies are one way of maintaining continuity in a Web application—that is, of performing state management. Except for the brief time when they are actually exchanging information, the browser and Web server are disconnected. Each request a user makes to a Web server is treated independently of any other request. Many times, however, it's useful for the Web server to recognize users when they request a page. For example, the Web server on a shopping site keeps track of individual shoppers so the site can manage shopping carts and other user-specific information. A cookie therefore acts as a kind of calling card, presenting pertinent identification that helps an application know how to proceed.
Cookies are used for many purposes, all relating to helping the Web site remember users. For example, a site conducting a poll might use a cookie simply as a Boolean value to indicate whether a user's browser has already participated in voting so that the user cannot vote twice. A site that asks a user to log on might use a cookie to record that the user already logged on so that the user does not have to keep entering credentials.
Cookie Limitations
Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. The user ID can then be used to identify the user and read user information from a database or other data store. (See the section "Cookies and Security" below for information about security implications of storing user information.)
Browsers also impose limitations on how many cookies your site can store on the user's computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined.
A cookie limitation that you might encounter is that users can set their browser to refuse cookies. If you define a P3P privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site. However, you might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common method for storing user information is session state, but session state depends on cookies, as explained later in the section "Cookies and Session State."
What is a good C# ASP.NET MVC question to ask a prospective employee?
First things first. Do they even know what MVC. Not just the TAL but can they describe it to you. Then what are the benefits. Also it doesn't hurt to ask them their opinion on it. It is good to know if they even like MVC frameworks.
Next, ask them if they have used any other MVC frameworks. Struts, Spring MVC, Zend or anything like that.
Ask them if they know when a session starts, the general state problem on the net etc etc.
Also a little bit of database. Ask them if they have any experience with database persistence layers.
Then just because you can ask a hard technical question, ask them to write a function that compares two binary trees both in value and structure to see if they are identicial.
ASP.NET Interview Questions: ViewState
(1) Does the performance for view state vary according to User controls?
Performance of view state varies depending on the type of server control to which it is applied. Label, Text Box, Check Box, Radio Button, and Hyper Link are server controls that perform well with View State. Drop Down List, List Box, Data Grid, and Data List suffer from poor performance because of their size and the large amounts of data making roundtrips to the server.
(2) What is View State?
View state is a built-in structure for automatically retaining values amongst the multiple requests for the same page. The view state is internally maintained as a hidden field on the page but is hashed, providing greater security than developer-implemented hidden fields do.
(3) What are benefits and Limitation of using View state for state management?
Following are the benefits of using View state:-
. No server resources are required because state is in a structure in the page code.
. Simplicity.
. States are retained automatically.
. The values in view state are hashed, compressed, and encoded, thus representing a higher state of security than hidden fields.
. View state is good for caching data in Web frame configurations because the data is cached on the client.
Following are limitation of using View state:-
. Page loading and posting performance decreases when large values are stored because view state is stored in the page.
. Although view state stores data in a hashed format, it can still be tampered because it is stored in a hidden field on the page. The information in
the hidden field can also be seen if the page output source is viewed directly, creating a potential security risk.
Below is sample of storing values in view state.
this. ViewState ["Enter Time"] = Date Time. Now. To String();
ASP.NET Interview Questions: Different States in ASP.NET
You can see that a browser on the client side requests a page from the web server. After processing the request and returning the page, the server drops the connection. Then. if the browser makes another request the server has no way to associate the browser with the previous request. So HTTP is called as a stateless protocol. But ASP.NET provides several ways to maintain the state.
View State
View state is used to maintain the values of server control properties. AS ASP.NET implements view state by default you need not to write any special code to use it.
Session State
Session state is used to maintain data between execution of an application. For this, ASP.NET creates a session state object that is kept on the server whenever a user starts a new session. The session state object contain unique session ID, and this ID is sent back and forth between the server and browser each time the user request a page. Then when the server receives a new request from the user, it can retrive the right session state object for that user. You can add data items to the session object in your code, so there previous values are available each time a web form is executed.
Application State
ASP.NET provides an application state object to save application state data, which applies to all the users of an application. You can use application state object to manage global counters to maintain a list of users who are currently logged on to an application.
Profile
ASP.NET also provides profile feature to keep track of user data. Although a profile is similar to session state object, it persists between user session as it is stored in a database. For example we can use profiles we can keep track of the products ordered by an user in an shopping application and when the user starts a new session, you can display those products in a "ordered items" listbox.
asp.net interview questions: state management
- What is the lifespan for items stored in ViewState?
Item stored in ViewState exist for the life of the current page. This includes postbacks (to the same page). - What is ViewState?
ViewState allows the state of objects (serializable) to be stored in a hidden field on the page. ViewState is transported to the client and back to the server, and is not stored on the server or any other external source. ViewState is used the retain the state of server-side objects between postabacks. - What are the different types of Session state management options available with ASP.NET?
ASP.NET provides In-Process and Out-of-Process state management. In-Process stores the session in memory on the web server. This requires the a "sticky-server" (or no load-balancing) so that the user is always reconnected to the same web server. Out-of-Process Session state management stores data in an external data source. The external data source may be either a SQL Server or a State Server service. Out-of-Process state management requires that all objects stored in session are serializable. - What does the "EnableViewState" property do? Why would I want it on or off?
It allows the page to save the users input on a form across postbacks. It saves the server-side values for a given control into ViewState, which is stored as a hidden value on the page before sending the page to the clients browser. When the page is posted back to the server the server control is recreated with the state stored in viewstate.
