- HTTP and State Information
- Cookies
- Session Variables
- Hidden HTML Form Fields
- URL Query String Values
- Roll Your Own Solution
- Review
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Roll Your Own Solution
If you are using ASP to develop a small Web application—if you are certain that its users will have cookies enabled, and the number of users will remain small enough that you won't have scalability problems—using ASP Sessions to store user state information is a good choice. Otherwise, you are wise to spend a little extra development time to create your own technique for maintaining state information.
Creating your own technique requires you to solve several problems. First, you need a way to identify each user of your application. Second, you need somewhere to store state information, either on the client or server. And finally, you need some way of deleting expired state data. The extra development time really isn't that much, and it can easily be adapted to work for all future Web applications once you have a technique working for one Web application. In my next article, I'll demonstrate one such technique.
Identifying Users
Identifying a user usually involves generating some kind of unique identifier and then including this identifier on each request from the user to the server. A unique identifier can be generated using any number of algorithms. It could be based on a random number; the current date and time; a Globally Unique Identifier (GUID); a UserID, if the user is required to logon to your application; a record ID, if you store state information in a relational database; or any combination of these. To include the identifier on each request from the user to the server, you could save it in a cookie (just like ASP Sessions), hide it in hidden HTML form fields, or add it to the URL as a query string parameter (my personal favorite).
State Information Storage
Most references I read suggest storing state information on the server so that the user can't tamper with it. Once you commit to keeping state information on the server, you've got several good choices for where on the server. If it is stored in the server's memory, you'll have the same scalability problems as ASP Sessions. Alternatively, each user's state information can be stored as a single row in a relational database table with the primary key being the user's unique identifier. With this technique, each data item can be stored in a separate column, or sometimes it is all strung together as a big XML string and stored in a single text column. This XML approach is more flexible because it allows new data items to be stored without making database table definition changes, but it does require extra processing time to format and parse the XML string. A simpler approach is to store each user's state information in a simple binary or text file with the user's unique identifier as the filename.
Deleting Expired Data
If you store state information on the server in a database table or in a file, you need some mechanism to delete it once it is no longer needed. Recall that in the HTTP protocol the server never really knows when the user has finished using your Web application, so even if your application has some sort of action you want the user to do when they are finished (such as completing an order or logging out), you will still need some sort of external method of deleting unused state data.
If the state data is stored in a relational database table, include a timestamp column that indicates when the row was last updated. Then, execute an SQL bulk delete statement that deletes all records with a timestamp older than whatever you want the expiration period to be. If the state information is stored in simple files, search the folder containing the state files, note the date last modified for each, and delete those files—with date last modified older than whatever you want the expiration period to be. Of course, either of these processes should be coded into simple executable and scheduled to run periodically using a scheduling program.