More on Storing Session State
I read Susan Perschke's article "A Recipe for Replacing Session Variables" (March 2006, InstantDoc ID 49114), which describes using a back-end SQL Server database to store session state, and I agree that this is an excellent solution. I've been using this technique for a number of years now. The only spin I've put on it is that I save the session information in the form of an XML document. The back-end SQL table has three columns: SessionID (randomly generated), Session XML (the XML document), and SessionExpires, a date/time field indicating when to purge the table row. This date-time column is updated (one day is added) on each visit to the Web server. This aids in maintaining the table size during database maintenance procedures.
I've created a class library called, oddly enough, SessionState. This library is written in .NET and incorporates, among others, the System.XML namespace and contains functions to Add, Update, Delete elements and attributes; Create, Clear, Delete session objects; and Retrieve and Save the current XML document. It basically wraps the functionality of System.XML into a small set of user-friendly functions for Document Object Model manipulation, and wraps System.Data for persistence.
Using this technique, I've virtually eliminated having to pass parameters via URL or hidden form fields. The technique has never failed and has simplified our development efforts. It also has opened the door to true load balancing in our Web farm.
One serendipitous use of this approach is that a customer support person can "jump into" another user's session simply by opening a support Web page and selecting the appropriate session from a list of saved sessions currently in the back-end SQL table. The support person can then reproduce any erroneous behavior that the user may be reporting.
I knew I couldn't be the only person
doing this. It's just that good.
—Michael Lopez
Date Formats
I was disappointed to read an IT pro recommending anything other than ISO/ODBC date formats in a select statement, in Michael Otey's Select Top(X): "T-SQL's Datetime Data Type" (September 2004, InstantDoc ID 43488). Americans probably don't see what the big deal is with writing dates "backwards" (mm/dd/yyyy). But there is a world outside the United States, and the rest of the world writes dates in the more logical format of dd/mm/yyyy or yy/mm/ dd. More logical because the order of the significance of the parts either increases (dd/ mm/yyyy, as in UK format) or decreases (yy/mm/dd, as in Korean format). The illogical US format mixes the significance of the parts and is akin to writing a time of 30 minutes and 45 seconds past 10:00 in the morning as 10:45:30 or 45:10:30. I was disappointed that Mr. Otey indirectly encouraged the representation of dates as "May 15, 2004 4 am," "5/15/2004 04:30," and "May 15, 2004." You might not see the significance of this, but in my opinion it's irresponsible of you to publish, in a global resource, anything other than unambiguous format.
—Daniel Clarke
Thanks!
Dawn Cyr did a great job with the article "What Makes YOU an Expert?" (December 2006, InstantDoc ID 94006). My boss read it and said that she would pay for my Microsoft certification. Hopefully, by next fall I will have earned the certification.
Virtualized Analytical Database Servers
I just read Michael Otey's editorial "The High Cost of Server Sprawl" (December 2006, InstantDoc ID 94062). I always appreciate his perspective. Recently, I've been trying to get a SQL Server 2005 environment in place at work. This is a Sybase shop, and I'm facing, to say the least, some resistance. But the IT staff created a SQL Server 2005 server for me—then I realized that it's running under VMware. The database space I live in is analysis and reporting, and not of a transactional nature. I've always believed that virtualization and analytical database servers aren't a good mix, due to the added OS/VMware software layer. But the staff here runs the server against a robust SAN, which could mitigate potential performance problems. Where does Michael come down on the issue of VMware and analytical database server implementations (i.e., data warehouse, data marts/dim models, OLAP)? When I searched on the Web, I found little commentary on this topic.
—John E. "Jody" Pilsworth
Depending on the requirements, I think that running SQL Server/OLAP from a virtual machine
(VM) using a SAN back end can be successful. A VM won't offer the same performance as a
physical server, but it can come close, and in most cases can be set up to meet the needs of users.
One of the most important factors is ensuring that the VM running SQL Server/OLAP has
been allocated an adequate amount of memory and that you've used a fixed-size virtual hard
disk.
—Michael Otey
