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
