A common and timeless problem for Web applications is state persistence. HTTP, which the Web depends on, is an inherently stateless protocol in the sense that each user request is served independently from the connected user. The application must keep track of the different users accessing the functions and use this information to reply accordingly to the user's permissions, privileges, and preferences.
In one way or another, you need to persist an application's state on the server and retrieve it later. Cookies are one possible approach, but they're subject to a browser's preferences and aren't completely reliable. Session variables are useful as long as the session is up and running; application-level variables persist only a bit longer.
If you use Active Server Pages (ASP) to develop a Web application, you might find it natural to store session variables in a SQL Server database and retrieve them later to show a certain continuity in the user's experience. Doing so is certainly good. But how do you architect the storage? What information should you save, and how should you organize it?
Obviously, anything that uniquely identifies the user is the key field where you should put the index. How much other information you need to store depends on the application's specific features, but in general, you will need one or two records with several fields. The only problem with this approach is that you must query several fields and keep the database server busy for longer than necessary. How can you shorten the time? By using XML, of course! The idea is to use XML to gather in a single text string all the information you need to preserve and store the string in a single database field.
After you extract such a text string, to make it useable, you need to parse it. An XML string becomes useable and advantageous as long
as you create an in-memory representation of it—normally an object model—that exposes methods and properties. If you're already using XML in your applications, storing all session variables as an XML string doesn't add any overhead.
In an ASP application, you enumerate the session variables through the Session.Contents and Session.StaticObjects collections. Session.Contents returns a collection of all the variables and their values stored in a particular Session object and not defined using the <OBJECT> tag (e.g., arrays). Session.StaticObjects returns a collection of all the variables stored using the <OBJECT> tag. The following pseudocode illustrates how you enumerate this content:
For Each v In session.Contents
' do something
Next
A good XML schema for this kind of information would be
<session> <contents> <variable name=. . .>value</varname> <variable name=. . .>value</varname> : </contents> <staticobjects> <variable id=. . ./> <variable id=. . ./> : </staticobjects> </session>
Such a schema faithfully maps the ASP content you want to persist. (Of course, you need to devise a schema that works in your particular context.) Notice that an ID represents static objects, and static objects don't have content.
The following piece of ASP code puts this schema into practice:
<% buf = "<session>" buf = buf & "<contents>" For Each v In session.Contents buf = buf & <variable name=" & Quote(v) & ">" buf = buf & Session.Contents(v) & "</variable> Next buf = buf & "</contents>"
buf = buf & "<staticobjects>" For Each v In session.StaticObjects buf = buf & <variable id=" & Quote(v) & ">" Next buf = buf & "</staticobjects>" buf = buf & "</session>"
You can also persist to XML Application object content, as well as any other data you might need to. Because you produce a simple string, it's easy to store and read from the database.