Technically, the model is supposed to be the same no matter what model. In
reality, there are bumps.
I am not sure about the state_end condition, as I rarely stick things into
session that cannot be automagically cleaned up, if I use session at all.
Someone else will have to tackle that one, but I would assume it works
pretty much the same, with the exception of potentially having that event
fire on multiple machines. No big deal really, as the actual state mechanism
is centralized.
What is the benefit? Scalability primarily. You can add machines to your web
farm without worrying about controlling state. If you have to keep state
over a failure, there is also SQL Server as an option. Note that you do
trade a bit of performance for this scalability.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
*********************************************
Think outside the box!
*********************************************
"Smokey Grindle" <no****@dontspamme.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
What are the advantages of using ASP.NET's session state server service
over using InProc state sessions? Also if you have a state server service
running, is there any way to find out when a session ended? with the
inproc ones you can use the global.asax's session_ended method...