session state is maintained by a httpmodule. All HttpModules used for a page
request are created and destroyed on each page request. HttpModules
implement two methods: Init & Dispose
the default sql session handler is very simple. on each page request, a new
Session object is created,
Init- this is when the session data is read from the sqlserver and
serialized back into objects
Dispose - this is when it serializes the data out to the sqlserver.
with sqlserver session state, the objectes are serialized to to a table,
and deleted by a stored proc that is run on a schedule.
the stateServer works as above, but rather than storing the xml in a table,
its stored in a hashtable on the shared server.
the inproc session manager stores a reference to the actual object in a
static hash table and thus requires no serialization. it runs a timer to
know when to free up session objects, and fire on session end event, when
this happens.
-- bruce (sqlwork.com)
"John Q. Smith" <an*******@discussions.microsoft.com> wrote in message
news:0e****************************@phx.gbl...
I'm trying to find out some of the details behind OOP
state management with SQL Server. For instance
- how long does the session object live on any server? Is
it created and destoyed with each page request?
- will each reading of a session variable cause a round
trip to the DB server? or does the complete session live
within the HttpContext object?
- when asp.net session state is enabled (in any mode),
after a session has been created, will it always be called
up into the HttpContext object with every page request,
even when no reads or writes to session variables occur?
- I've read that both OOP options must
serialize/deserialize the session data, so is the only
performance difference between stateServer and SQLServer
the overhead involved with accessing/reading/locking the
DB?
thanks for any info provided
- John
