A Scalable Alternative to Session VariablesBy 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
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.
|Field Name||Data type||other info|
|Field Name||Data type||other info|
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
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!