While the Application object is little changed from earlier versions of ASP, the Session object in ASP+ has undergone some quite dramatic updating. It is still compatible with code from earlier versions of ASP, but has several new features that make it even more useful.
The biggest change is that the contents of the Session object can now (optionally) be stored externally from the ASP+ process, in a new object called a Session State Store. It is managed by a new Windows service called the State Server Process, and this persists the content of all users Session objects – even if the ASP+ process they are running under fails. It also removes the content of sessions that have terminated through a time-out or after an error.
Alternatively, the Session content can be serialized out into a temporary SQL Server database table, where ASP+ talks directly to SQL Server. This means that it can be reloaded after an application or machine failure, providing a far more robust implementation of Session object storage than previous versions. It's therefore ideal for applications that require a session-level state management feature, for example a shopping cart.
This new state storage system also has another direct advantage. When using a Web farm to support a large-scale application or Web site it has always been a problem managing sessions, as they are not available across the machines in the Web farm.
The new ASP+ Session State Store can be partitioned across multiple servers, so that each client's state can be maintained irrespective of which server in the Web farm they hit first.
At last, ASP+ also allows session state to be maintained for clients that don't support cookies. This was proposed in earlier versions of ASP, but never materialized. Now, by using a special configuration setting, you can force ASP+ to 'munge' the session ID into the URL. This avoids all of the previously encountered problems of losing state information, for example when the URLs in hyperlinks do not use the same character case as the page names.
Finally, the State Server Process will also be able to expose information about
the contents of the Session State Store, which will be useful for performance
monitoring and administrative tasks such
as setting maximum limits for each client's state. We examine the way that sessions
can be managed
in Chapter 6.
ASP+ Error Handling, Debugging, and Tracing
Error handling and debugging has long been an area where ASP trailed behind other development environments like Visual Basic and C++. In ASP+, there are several new features that help to alleviate this situation. It's now possible to specify individual error pages for each ASP+ page, using the new ErrorPage directive at the start of an ASP+ page:
<%@Page ErrorPage="/errorpages/thispage.aspx"%>
If a 'Not Found', 'Access Forbidden' response is generated, or an 'Internal Server Error' (caused by an ASP code or object error) occurs while loading, parsing, compiling or processing the page, the custom error page you specify is loaded instead. In this page, you can access the error code, the page URL, and the error message. The custom error page, or other error handler, can alternatively be specified in the config.web file for an application.
If no error page is specified then ASP+ will load its own error page, which contains far more detail than before about the error and how to rectify it. Settings in the config.web file also allow you to specify that this information should only be presented to a browser running on the Web server, and in this case remote users will just receive a simple error indication. Alternatively, you can create a procedure in the ASP+ page that captures the HandleError event, and doing so also prevents the default error page from being displayed.
Another welcome new feature is that Visual Basic now supports the try...catch...finally error handling technique that has long been the mainstay in languages like C++, and more recently in JScript. More details of this can be found in Appendix B. ASP+ also improves debugging techniques by including a new Debugger tool. This is the same debugger that is supplied with Visual Studio, allowing local and remote debugging.
Finally, ASP+ now includes comprehensive tracing facilities, so you no longer need to fill your pages with Response.Write statements to figure out what's going on inside the code. Instead, by turning on tracing at the top of the page with the new Trace directive, you can write information to the Trace object and have it rendered automatically as an HTML table at the end of the page. Tracing can also be enabled for ASP+ applications by adding instructions to the config.web file. The trace information automatically includes statistics that show the response time and other useful internal parameters:
|
|
On top of this, a Web-based viewer is provided that allows you to examine the contents of the TraceContext object's log file. We look at the whole topic of error handling, debugging and tracing in Chapter 4.
Other ASP+ Features
To finish off this brief tour of the new features in ASP+, we'll look at some other topics that fall under the 'general' heading. These include security management, sending e-mail from ASP+ pages, and server-side caching.
Comments