To read the article online, visit http://www.4GuysFromRolla.com/webtech/041600-2.shtml

A Scalable Alternative to Session Variables

By Scott Sargent


In many mailing lists, message boards and websites I have seen people protesting about how evil session variables are & how they limit the scalability of our websites. These people are correct the Session variables are in fact evil; unfortunately life is never so simple. As evil as they are as performance degrading as they can be they are incredibly useful. This is a real dilemma for many of us: Performance vs. Ease & functionality? What do we do? There have been many alternatives & ideas proposed, here are a few:

    1. Use Client side cookies - This is a good alternative to session, it's more scalable & probably more efficient than session variables are, this method is not with out its faults though. The biggest fault with this method is that it absolutely requires the user to have cookies enabled on their browser (the Session Object has the exact same requirement). In highly secure situations a user may not have cookies enabled so this method wouldn't work for them.

    2. Pass all state information in the query string - This is also a good method & much more scalable than the session object. Again this method has a few cons against it. First, this method can lead to very complex querystrings & things will get confusing, as all state information would have to be passed back & forth within each page. Also if a user clicked off of your site then came back with out hitting the back button all the information would be lost. Again perhaps there is a better way of doing it.

    3. Pass everything in Hidden form fields - This method features less complicated querystrings, & is just as fast/scalable as the previous method. Unfortunately it requires you to submit a form on every page. This also is perhaps the most complicated to code/implement on a large site. This also has the problem of what if a user leaves & comes back. We need to replace session variables with a more efficient method at the same time we need the functionality that they bring us.

    4. Pass a GUID in the querystring that references fields in a database - This is my favorite method & the method I will spend the rest of the article talking about. Lets take a quick look at what this brings us. Unlimited storage, you could have a million Session Type variables stored in the database & it would be the same level of complexity as if you had only one. Ease of use, all we have to do is to pass the GUID in the querystring, that's it. if the user clicks off the site & comes back on we can look up that user's GUID for that session because we are using a database (I'll explain more later). To start off with let's call this method the GUIDSession, that way we won't get confused between this and the Session object. The GUIDSession method is basically composed of a database featuring two tables and four stored procedures. On the web server side, there are four primary functions; these could be in an .asp file that is included or a Component of some sort. For simplicity I will write them as an ASP file. And that's it. that's all there is to this method. Now for the details...
    (This is not a complete list I am sure there are other ways to do it)

(For a more thorough discussion on various ways to maintain state be sure to read the free sample chapter from Sams Teach Yourself Active Server Pages 3.0 in 21 Days.)

First our Database design. For this article I'll be using MS SQL Server 7.0. I will check the code & stored procedures so I know that they work under that system.

TABLE SESSIONS
Field NameData typeother info
sessioniduniqueidentifierPrimary Key
time_stampdatetime 
sessionipaddrvarchar(50) 

TABLE SESSIONVALUES
Field NameData typeother info
sessionidvarchar(50)Primary Key
sessionvalnamevarchar(100)Primary Key
sessionvaldatavarchar(100) 

Now our Stored Procedures. The stored procedures serve four functions:

    1.) To initially assign the GUID
    2.) To write the name/value pairs
    3.) To retrieve the name/value pairs
    4.) To retrieve a GUID if it gets lost.

The first one will simply assign the new user a GUID

CREATE Procedure newsession
	@USRIPADDR VARCHAR(50)
AS
	DECLARE @SESSIONID UNIQUEIDENTIFIER
	SET @SESSIONID = NEWID()
	DECLARE @DT DATETIME
	SET @DT = getdate()
	INSERT INTO SESSIONS 
	(SESSIONID, TIME_STAMP, SESSIONIPADDR)
	VALUES
	(@SESSIONID, @DT, @USRIPADDR)
	SELECT SESSIONID FROM SESSIONS WHERE SESSIONID = @SESSIONID

The second one is the most complex it writes the name value pairs to the database. We'll look at this stored procedure in Part 2!

  • Read Part 2


  • Article Information
    Article Title: A Scalable Alternative to Session Variables
    Article Author: Scott Sargent
    Published Date: Sunday, April 16, 2000
    Article URL: http://www.4GuysFromRolla.com/webtech/041600-2.shtml


    Copyright 2017 QuinStreet Inc. All Rights Reserved.
    Legal Notices, Licensing, Permissions, Privacy Policy.
    Advertise | Newsletters | E-mail Offers