Now that I've learned how to spell "Recommendations"
here's part two of the article, dealing with server side state management.
Jack
Server-Side State Management Options
Server-side options for storing page information tend to have higher security than client-side options, but they can use more Web server resources, which may lead to scalability issues when the size of the information store is large. ASP.NET provides several options to implement server-side state management. For more information, see Introduction to Web Forms State Management.
Application State
ASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific information that is visible to the entire application. Application state variables are, in effect, global variables for an ASP.NET application. For more information, see Application State.
You can store your application-specific values in application state, which is then managed by the server. For more information, see Introduction to Web Forms State Management.
The ideal data to insert into application state variables is data that is shared by multiple sessions and does not change often.
Note If you store a dataset in application state, you have to cast it from Object back to a dataset. For details, see Web Data Access Strategy Recommendations.
The advantages of using application state are:
Ease of implementation. Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Global scope. Because application state is accessible to all pages in an application, storing information in application state can mean keeping only a single copy of the information (for instance, as opposed to keeping copies of information in session state or in individual pages).
The disadvantages of using application state are:
Global scope. The global nature of application state can also be a disadvantage. Variables stored in application state are global only to the particular process the application is running in, and each application process can have different values. Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-farm configurations.
Durability. Because global data stored in application state is volatile, it will be lost if the Web server process containing it is destroyed, most likely from a server crash, upgrade, or shutdown.
Resource requirements. Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.
Careful design and implementation of application state can increase Web application performance. For example, placing a commonly used, relatively static dataset in application state can increase site performance by reducing the overall number of data requests to a database. However, there is a performance trade-off. Application state variables containing large blocks of information reduce Web server performance as server load increases. The memory occupied by a variable stored in application state is not released until the value is either removed or replaced. Therefore, it is best to use application state variables only with small, infrequently changed datasets. For more information on optimizing ASP.NET Web applications, see ASP.NET Optimization.
Session State
ASP.NET provides a session state, available as the HttpSessionState class, as a method of storing session-specific information that is visible within the session only. For more information, see Introduction to Web Forms State Management and Session State.
You can store your session-specific values and objects in session state, which is then managed by the server and available to the browser or client device. The ideal data to store in session-state variables is short-lived, sensitive data that is specific to an individual session.
Note If you store a dataset in application state, you have to cast it from Object back to a dataset. See Web Data Access Strategy Recommendations.
The advantages of using session state are:
Ease of implementation. The session state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Session-specific events. Session management events can be raised and used by your application.
Durability. Data placed in session-state variables can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space.
Platform scalability. Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. For more information on using session state without cookies, see ASP.NET Configuration Sections.
For more information, see Session State.
The disadvantage of using session state is:
Performance. Session state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session state variables containing blocks of information like large datasets can adversely affect Web server performance as server load increases.
Database Support
In some cases, you may wish to use database support to maintain state on your Web site. Typically, database support is used in conjunction with cookies or session state. For example, it is quite common for an e-commerce Web site to maintain state information using a relational database for the following reasons:
Security
Personalization
Consistency
Data mining
The following are typical features of a cookie-supported database Web site:
Security. The visitor types an account name and password into a site logon page. The site infrastructure queries the database with the logon values to determine if the user has rights to utilize your site. If the database validates the user information, the Web site will distribute a valid cookie containing a unique ID for that user on that client computer. The site grants access to the user.
Personalization. With security information in place, your site is able to distinguish each user on your site by reading the cookie on the client computer. Typically, sites have information in the database that describes the preferences of a user (identified by a unique ID). This relationship is known as personalization. The site can research the user's preferences using the unique ID contained in the cookie, and then place content and information in front of the user that pertains to the user's specific wishes and reacts to the user's preferences over time.
Consistency. If you have created a commerce Web site, you may wish to keep transactional records of purchases made for goods and services on your site. This information can be reliably saved in your database and referenced by the user's unique ID. It can be used to determine if a purchase transaction has been completed, and also to determine the course of action should a purchase transaction fail. The information may also be used to inform the user of the status of an order placed using your site.
Data mining. Information about your site usage, your visitors, or your product transactions can be reliably stored in your database. For example, your business development department may wish to use this data collected from your site to determine next year's product line or distribution policy. Your marketing department may wish to examine demographic information about users on your site. Your engineering and support department may wish to look at transactions and note areas where your purchasing process could be improved. Most enterprise-level relational databases such as Microsoft SQL Server contain an expansive toolset for most data mining projects.
By designing the Web site to repeatedly query the database by using the unique ID during each general stage in the above scenario, the site maintains state. In this way, the user perceives that the site is remembering and reacting to him or her personally.
The advantages of using a database to maintain state are:
Security. Access to databases is typically very secure, requiring rigorous authentication and authorization.
Capacity. You can store as much information as you like in a database.
Persistence. Database information can be stored as long as you like, and it is not subject to the availability of the Web server.
Robustness and data integrity. Databases include various facilities for maintaining good data, including triggers and referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.
Accessibility. The data stored in your database is accessible to a wide variety of information-processing tools.
Wide support. There is a large range of database tools available, and many custom configurations are available.
The disadvantages of using a database to maintain state are:
Complexity. Using a database to support state management implies more complex hardware and software configurations.
Performance. Poor construction of the relational data model can lead to scaling issues. Also, leveraging too many queries to the database can adversely affect server performance.
here's part two of the article, dealing with server side state management.
Jack
Server-Side State Management Options
Server-side options for storing page information tend to have higher security than client-side options, but they can use more Web server resources, which may lead to scalability issues when the size of the information store is large. ASP.NET provides several options to implement server-side state management. For more information, see Introduction to Web Forms State Management.
Application State
ASP.NET provides application state via the HttpApplicationState class as a method of storing global application-specific information that is visible to the entire application. Application state variables are, in effect, global variables for an ASP.NET application. For more information, see Application State.
You can store your application-specific values in application state, which is then managed by the server. For more information, see Introduction to Web Forms State Management.
The ideal data to insert into application state variables is data that is shared by multiple sessions and does not change often.
Note If you store a dataset in application state, you have to cast it from Object back to a dataset. For details, see Web Data Access Strategy Recommendations.
The advantages of using application state are:
Ease of implementation. Application state is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Global scope. Because application state is accessible to all pages in an application, storing information in application state can mean keeping only a single copy of the information (for instance, as opposed to keeping copies of information in session state or in individual pages).
The disadvantages of using application state are:
Global scope. The global nature of application state can also be a disadvantage. Variables stored in application state are global only to the particular process the application is running in, and each application process can have different values. Therefore, you cannot rely on application state to store unique values or update global counters in Web-garden and Web-farm configurations.
Durability. Because global data stored in application state is volatile, it will be lost if the Web server process containing it is destroyed, most likely from a server crash, upgrade, or shutdown.
Resource requirements. Application state requires server memory, which can affect the performance of the server as well as the scalability of the application.
Careful design and implementation of application state can increase Web application performance. For example, placing a commonly used, relatively static dataset in application state can increase site performance by reducing the overall number of data requests to a database. However, there is a performance trade-off. Application state variables containing large blocks of information reduce Web server performance as server load increases. The memory occupied by a variable stored in application state is not released until the value is either removed or replaced. Therefore, it is best to use application state variables only with small, infrequently changed datasets. For more information on optimizing ASP.NET Web applications, see ASP.NET Optimization.
Session State
ASP.NET provides a session state, available as the HttpSessionState class, as a method of storing session-specific information that is visible within the session only. For more information, see Introduction to Web Forms State Management and Session State.
You can store your session-specific values and objects in session state, which is then managed by the server and available to the browser or client device. The ideal data to store in session-state variables is short-lived, sensitive data that is specific to an individual session.
Note If you store a dataset in application state, you have to cast it from Object back to a dataset. See Web Data Access Strategy Recommendations.
The advantages of using session state are:
Ease of implementation. The session state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.
Session-specific events. Session management events can be raised and used by your application.
Durability. Data placed in session-state variables can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space.
Platform scalability. Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.
Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. For more information on using session state without cookies, see ASP.NET Configuration Sections.
For more information, see Session State.
The disadvantage of using session state is:
Performance. Session state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session state variables containing blocks of information like large datasets can adversely affect Web server performance as server load increases.
Database Support
In some cases, you may wish to use database support to maintain state on your Web site. Typically, database support is used in conjunction with cookies or session state. For example, it is quite common for an e-commerce Web site to maintain state information using a relational database for the following reasons:
Security
Personalization
Consistency
Data mining
The following are typical features of a cookie-supported database Web site:
Security. The visitor types an account name and password into a site logon page. The site infrastructure queries the database with the logon values to determine if the user has rights to utilize your site. If the database validates the user information, the Web site will distribute a valid cookie containing a unique ID for that user on that client computer. The site grants access to the user.
Personalization. With security information in place, your site is able to distinguish each user on your site by reading the cookie on the client computer. Typically, sites have information in the database that describes the preferences of a user (identified by a unique ID). This relationship is known as personalization. The site can research the user's preferences using the unique ID contained in the cookie, and then place content and information in front of the user that pertains to the user's specific wishes and reacts to the user's preferences over time.
Consistency. If you have created a commerce Web site, you may wish to keep transactional records of purchases made for goods and services on your site. This information can be reliably saved in your database and referenced by the user's unique ID. It can be used to determine if a purchase transaction has been completed, and also to determine the course of action should a purchase transaction fail. The information may also be used to inform the user of the status of an order placed using your site.
Data mining. Information about your site usage, your visitors, or your product transactions can be reliably stored in your database. For example, your business development department may wish to use this data collected from your site to determine next year's product line or distribution policy. Your marketing department may wish to examine demographic information about users on your site. Your engineering and support department may wish to look at transactions and note areas where your purchasing process could be improved. Most enterprise-level relational databases such as Microsoft SQL Server contain an expansive toolset for most data mining projects.
By designing the Web site to repeatedly query the database by using the unique ID during each general stage in the above scenario, the site maintains state. In this way, the user perceives that the site is remembering and reacting to him or her personally.
The advantages of using a database to maintain state are:
Security. Access to databases is typically very secure, requiring rigorous authentication and authorization.
Capacity. You can store as much information as you like in a database.
Persistence. Database information can be stored as long as you like, and it is not subject to the availability of the Web server.
Robustness and data integrity. Databases include various facilities for maintaining good data, including triggers and referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.
Accessibility. The data stored in your database is accessible to a wide variety of information-processing tools.
Wide support. There is a large range of database tools available, and many custom configurations are available.
The disadvantages of using a database to maintain state are:
Complexity. Using a database to support state management implies more complex hardware and software configurations.
Performance. Poor construction of the relational data model can lead to scaling issues. Also, leveraging too many queries to the database can adversely affect server performance.
