Using XML to Maintain Client State

Using XML to Maintain Client State - Part II

Originally Published 9/6/2000 on MCPCentral.com

This article is the second in a two-part series discussing the use of XML as a storage mechanism for maintaining the state of a web client. The first installment dealt with the advantages of using XML to maintain state, and began the process by designing and building a VB object to be used for this purpose. This second part deals with using the object created in part 1 from within ASP and compares the performance of the XML methodology with that of the Microsoft state mechanism.

Now that we have a working VB object that can replace the ASP native Session object, lets put together some ASP code that puts it to the test. We will create a simple ASP form that has two textboxes and a submit button. The first text box will be for a variable name and the second for the value to be associated with that variable. Upon submission, ASP code will accept these values and update the state mechanism to store the value provided, in the variable provided. The code for, and an image of this form is below:


    <TABLE WIDTH="100%">
        <FORM method="post" action="<%= Request.ServerVariables("PATH_INFO") %>">
            <TR>
                <TD align="right">Variable Name: </TD>
                <TD align="left"><input type="text" name="Name"></TD>
                <TD align="right">Value: </TD>
                <TD align="left"><input type="text" name="Value"></TD>
                <TD align="left"><input type="submit" value="Add"></TD>
            </TR>
        </FORM>
        <TR>
            <TD align="right" colspan="5">
                <a href="XMLLogout.asp">Logout</a>
            </TD>
        </TR>
    </TABLE>

Listing 1 - ASP Input Form

Figure 1 - ASP Input Form Viewed in a Browser

In addition to the form, you will notice the three variables and values displayed below the horizontal rule. These are enumerations of the default values stored in our collection by our state object upon instantiation. When data is entered into the boxes and submitted, the variable name and value is added to that collection. An example is shown below:

Figure 2 - ASP Input Form After Submission

The ASP code used to display these values is shown here:


    <%
        'Display all Data From State
        for each item in objSession.Keys
            response.write(item & " = " & objSession.Data(item) & "<BR>")
        next
    %>

Now that the preliminaries are out of the way, it’s time to get into the guts of the application. When the web server that maintains state with this methodology receives a request, the application needs to check for the presence of our cookie, which we will define as “XMLState” and give it the value of the GUID generated by the state object. If no cookie is found, we will start a new session using our state object and assign a cookie using that value. In this example, we set the cookie to last for 20 minutes but you can change that value as you see fit for your application. If our cookie is found, we load the existing state values, passing the value of the GUID from the cookie to our state object. We will also reset the expiration of the cookie to a fresh 20-minutes. This code snippet is shown below:


    <%
        sCookieName = "XMLState"

        'Instantiate State Object
        set objSession = server.CreateObject("XMLState.Session")

        'Check for our cookie
        if Trim(Request.Cookies(sCookieName)) = "" then
            sCookieValue = objSession.Start 'Start a new session
            Response.Cookies(sCookieName) = sCookieValue
            Response.Cookies(sCookieName).expires = DateAdd("n", 20, now())
        else
            sCookieValue = Request.Cookies(sCookieName)
            lResult = objSession.Load(sCookieValue) 'Load existing session
            if lResult<>0 then
                Response.Write("Error " & lResult & " in objSession.Load")
                Response.end
            end if
            Response.Cookies(sCookieName).expires = DateAdd("n", 20, now())
        end if
    %>

Listing 3 - ASP Code to Create/Update the Session

Now we need to load the submitted values (if there are any) into the state mechanism. The data is loaded from the form and the UpdateData method of the state object is used to add the variable and value (if the variable does not already exist in state) or update the value stored in that variable. This code can be seen here:


    <%
        'Load posted data
        sName = Trim(Request.Form("Name"))
        sValue = Trim(Request.Form("Value"))

        'If both form fields filled in, add data to State
        if sName<>"" and sValue<>"" then
            lResult = objSession.UpdateData(sName, sValue)
            if lResult<>0 then
                Response.Write("Error " & lResult & " in objSession.UpdateData<BR>")
                Response.End
            end if
        end if
    %>

Listing 4 - ASP Code to Update the State

Finally, at the end of each page load, we must save the results using the save method of the state object. We can also create a “logout” page that, in the case of this methodology, only releases the cookie. That page could also delete the leftover XML file if you so choose.

We will also create a set of pages that perform the identical functions using the ASP session object. While I will not go into detail about that code here, it can be downloaded along with the full source of the ASP and VB code previously described in this article and its predecessor. We will use these pages to run performance tests using Microsoft’s Web Application Stress tool (formerly known as Homer). For this example, I have chosen to create a script that starts a session, sets the value of 3 variables, updates the values of all three of those same variables, and then logs out. I ran these tests on a Pentium II, 333 single-processor server running NT 4.0 and IIS 4.0. There are many variables that can cause changes in these numbers so you should be sure to run your own tests prior to implementing this type of process in your eCommerce solution.

Figure 3 - Results of Load Testing

As you can see from the graph, at lower utilizations the Microsoft state mechanism performs better since it uses memory-resident variables. However, once the number of concurrent users begins approaching the limit of the server, both methodologies fall-off sharply in performance, but the XML state mechanism stays relatively steady after that, where the Session methodology continues to degrade as user-level increases. Again, your results will likely vary depending on your application and hardware so be certain to do your own performance testing before relying on any solution.