The Cache object is defined in the 'System.Web.Caching' namespace. You can get a reference to the Cache object by using the Cache property of the Http Context class in the 'System.Web' namespace or by using the Cache property of the Page object.

When you add an item to the cache, you can define dependency relationships that can force that item to be removed from the cache under specific activities of dependencies. Example if the cache object is dependent on file and when the file data changes you want the cache object to be update. Following are the supported dependency:-

File dependency: - Allows you to invalidate a specific cache item when a disk based file or files change.

Note:- Above source code can be obtained from CD in "'CacheSample"' folder. "'Announcement.txt"' is in the same folder which you can play around to see the results.

Above given method display Announcement() displays banner text from Announcement.txt file which is lying in application path of the web directory. Above method, first checks whether the Cache object is nothing, if the cache object is nothing then it moves further to load the cache data from the file. Whenever the file data changes the cache object is removed and set to nothing.

Cache object is dependent on its dependencies example file based, time based etc...Cache items remove the object when cache dependencies change.ASP.NET provides capability to execute a callback method when that item is removed from cache.

When server running your ASP. NET application runs low on memory resources, items are removed from cache depending on cache item priority. Cache item priority is set when you add item to cache. By setting the cache item priority controls, the items scavenging are removed according to priority.

You can use two types of output caching to cache information that is to be transmitted to and displayed in a Web browser:

Page Output Caching Page output caching adds the response of page to cache object. Later when page is requested page is displayed from cache rather than creating the page object and displaying it. Page output caching is good if the site is fairly static.

Page Fragment CachingIf parts of the page are changing, you can wrap the static sections as user controls and cache the user controls using page fragment caching.

Page fragment caching involves the caching of a fragment of the page, rather than the entire page. When portions of the page are need to be dynamically created for each user request this is best method as compared to page caching. You can wrap Web Forms user control and cache the control so that these portions of the page do not need to be recreated each time.

ASP session state is dependent on IIS process very heavily. So if IIS restarts ASP session variables are also recycled.ASP.NET session can be independent of the hosting environment thus ASP. NET session can be maintained even if IIS reboots.

ASP session state has no inherent solution to work with Web Farms.ASP.NET session can be stored in state server and SQL SERVER which can support multiple server.

ASP session only functions when browser supports cookies.ASP.NET session can be used with browser side cookies or independent of it.

In Proc: - In this mode Session, state is stored in the memory space of the Aspnet_wp.exe process. This is the default setting. If the IIS reboots or web application restarts then session state is lost.

State Server:-In this mode Session state is serialized and stored in a separate process (Aspnet_state.exe); therefore, the state can be stored on a separate computer (a state server).

SQL SERVER: - In this mode Session, state is serialized and stored in a SQL Server database.

Session state can be specified in <session State> element of application configuration file. Using State Server and SQL SERVER session state can be shared across web farms but note this comes at speed cost as ASP. NET needs to serialize and desterilize data over network repeatedly.

Following are the things to remember so that SQL SERVER Mode works properly:-

SQL SERVER mode session data is stored in a different process so you must ensure that your objects are serializable.

IIS met abase (\LM\W3SVC\2) must be identical across all servers in that farm.

By default Session objects are stored in "'Temped"', you can configure it store outside "'TempDB"' by running Microsoft provided SQL script.

Note:- "'TempDB"' database is re-created after SQL SERVER computer reboot.If you want to maintain session state with every reboot best is to run SQL Script and store session objects outside "'TempDB"' database.

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.

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.

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.

Above is a sample of hidden frames where the first frame "'data_of_frame1.html"' is visible and the remaining frames are hidden by giving whole col section to first frame. 100 % is allocated to first frame and remaining frames thus remain hidden.

A query string is information sent to the server appended to the end of a page URL.

Following are the benefits of using query string for state management:-

No server resources are required. The query string containing in the HTTP requests for a specific URL.

All browsers support query strings.

Following are limitations of query string:-

Query string data is directly visible to user thus leading to security problems.

Most browsers and client devices impose a 255-character limit on URL length.

Below is a sample "'Login"' query string passed in URL

http://www.querystring.com/login.asp?login=testing.

This query string data can then be requested later by using Request.QueryString("'login"').

(I) What is Absolute and Sliding expiration?

Absolute Expiration allows you to specify the duration of the cache, starting from the time the cache is activated. The following example shows that the cache has a cache dependency specified, as well as an expiration time of one minute.

Sliding Expiration specifies that the cache will expire if a request is not made within a specified duration. Sliding expiration policy is useful whenever you have a large number of items that need to be cached, because this policy enables you to keep only the most frequently accessed items in memory. For example, the following code specifies that the cache will have a sliding duration of one minute. If a request is made 59 seconds after the cache is accessed, the validity of the cache would be reset to another minute:

By default, button controls in ASP. NET pages post back to the same page that contains the button, where you can write an event handler for the post. In most cases this is the desired behavior, but occasionally you will also want to be able to post to another page in your application. The Server. Transfer method can be used to move between pages, however the URL does not change. Instead, the cross page-posting feature in ASP .NET 2.0 allows you to fire a normal post back to a different page in the application. In the target page, you can then access the values of server controls in the source page that initiated the post back.

To use cross page posting, you can set the PostBackUrl property of a Button, Link Button or Image Button control, which specifies the target page. In the target page, you can then access the Previous Page property to retrieve values from the source page. By default, the Previous Page property is of type Page, so you must access controls using the Find Control method. You can also enable strongly-typed access to the source page by setting the @Previous Page Type directive in the target page to the virtual path or Type name of the source page.

Here is a systematic guide for implementing the cross-page post back using controls that implement the I Button Control interface.

Create a Web Form and insert a Button control on it using the VS .NET designer.

Set the button's PostBackUrl property to the Web Form you want to post back. For instance in this case it is "nextpage.aspx"

<asp: Button ID="Button1" run at="server"PostBackUrl="~/nextpage.aspx" Text="Post to next page" />

When the PostBackUrl property of the I Button Control is set, the ASP .NET framework binds the corresponding HTML element to new JavaScript function named Web Form _Do Post Back With Options. The corresponding HTML rendered by the ASP .NET 2.0 will look like this:

View state is page specific; it contains information about controls embedded on the particular page. ASP.NET 2.0 resolves this by embedding a hidden input field name, __POST BACK. This field is embedded only when there is an IButtonControl on the page and its PostBackUrl property is set to a non-null value. This field contains the view state information of the poster page. To access the view state of the poster page, you can use the new Previous Page property of the page:

Page poster = this. Previous Page;

Then you can find any control from the previous page and read its state:

You can post back to any page and pages in another application, too. However, if you are posting pages to another application, the PreviousPage property will return null. This is a significant restriction, as it means that if you want to use the view state, you are confined, for example, posting to pages in the same virtual directory. Even so, this is a highly acceptable addition to the functionality of ASP.NET.

SQL cache dependencies is a new feature in ASP.NET 2.0 which can automatically invalidate a cached data object (such as a Dataset) when the related data is modified in the database. So for instance if you have a dataset, which is tied up to, a database tables any changes in the database table will invalidate the cached data object which can be a dataset or a data source.