Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Pooled Objects and Initialization Control in VS.NET

One of .Net's more obvious benefits for today's Visual Basic developers, is the ability to easily create poolable objects using Visual Basic.NET. The author demonstrates how a web application that uses poolable objects, can show a 50% performance boost in the rate of transactions per second when pooling is enabled. The article also covers things such as application configuration, string resources, page templates, and using XSL stylesheets.


advertisement
he Web application with which I am currently involved, relies heavily on external data abstractions to control both functionality, as well as the UI appearance. These external data repositories are all stored in XML format.
  • Application Configuration
  • Navigation Configuration (Modes, Modules and Menus)
  • XSL Stylesheets
  • String Resources
  • Page Templates

The benefits in storing this type of data externally is that the functionality, as well as the look-and-feel of the application can be changed quickly by simply altering the data in the appropriate external file. Need to add a new menu item? Simply modify the Navigation configuration file. Want to change the stylistic appearance of the UI? Simply modify the relevant XSL stylesheet and/or page templates. Need to correct a typo, or change a bit of verbiage? Simply make the modification in the string resource file. No code modifications are necessary in order to effect these, and other similar changes.

You might find it interesting to stop by www.FPSNow.com in order to take a look at the application which I’ve described. The site itself contains a wealth of documentation on how it is constructed which you may find interesting, as it relates to this article.

On the other hand, loading these data files, and instantiating the XML DOM’s (that’s the kicker) on each transaction would be an unnecessary burden since the same operation would be repeated over and over again for successive transactions. By pooling the objects, and leaving the internal DOM structures loaded, we can re-use initialization on successive transactions. As it turns out, pooling objects is simple with Visual Basic.NET.

Note: the following discussion presents a software solution which has been developed and tested under Windows 2000 Server exclusively. I have no experience with .NET in any previous environments and so I can't comment on whether the scenario I am about to present has any application to those environments at this time. (Although some aspects of what I am about to present can be useful at least in concept, if not in direct application.)

The .NET framework provides the IHttpHandler interface for objects instantiated via IIS. This interface provides the class with two important benefits.
  • The class will have access to the IIS HTTPContext.
  • The class can be pooled by IIS.

A class which implements IHttpHandler (I’ll call classes of this type, HTTPHandlers) is invoked by mapping a url to the class in the Web.config file which is present in the root folder of the application. Here are two lines which map two types of url’s to a Handler class.

<add verb="*" path="enternet.aspx" type="EnterNetMain.WAC, EnterNetMain" />
<add verb="*" path="*.htmx" type="EnterNetMain.WAC, EnterNetMain" />


According to these specifications, requesting the specific URL enternet.aspx, or any url ending in .htmx from this application site will cause IIS to instantiate a copy of EnterNetMain.WAC to handle the request. There doesn’t necessarily need to be any information inside of the designated url. For example, here is a listing of the file enternet.aspx, which is mapped in the first of the two statements above.

<%@ Page Language="vb" %>
<%
' This page does absolutely nothing. It simply serves as the
' cross-reference URI mapping to invoke the Web Application
' Controller, EnterNetMain.WAC.
%> 


As you can see, there’s nothing of substance in the file. The file just acts as a trigger’ to launch EnterNetMain.WAC, which is an HTTPHandler.

HTMX files (the .htmx extension is my own definition) are another matter completely. HTMX files contain data which is processed by the HttpHandler. The instance of the class instantiated (or selected from the pool) to process each particular request knows which particular HTMX file was requested since it has access to the HTTPContext.

Ultimately, whether the file indicated by the url has any meaningful information in it or not is up to your particular implementation. The only thing you need to understand, is how to map a particular url or group of url’s to an HTTPHandler, as described above.

There is one additional step which may need to be taken when mapping a url to an HTTPHandler and that is to ensure that the url is handled by the ASP.NET ISAPI (aspnet_isapi.dll). ASPX files are by default handled in this manner so if you simply want to map an ASPX file, all you need to do is make the appropriate entry in Web.config as shown above. HTMX files are a brand new file type though, so this new file type needs to be explicitly mapped to ASP.NET ISAPI. This is easily accomplished through the IIS management console. You can set the new mapping at the server, site or application level. Here’s how to set it at the application level.

  • Right-click on the application and select Properties.
  • On the Directory tab, click the Configuration button.
  • On the App Mappings tab click the Add button.
  • In the dialog enter the fully qualified path to the ASP.NET ISAPI DLL.
    (On my system it is C:\WINNT\Microsoft.NET\Framework\v1.0.2914\aspnet_isapi.dll)
  • Enter the extension you wish to map (e.g. .htmx - don’t forget the dot’)
  • Hit OK.




Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date