StateServer - when is the session serialised?

[Rob Nicholson]

I'm currently using InProc session which are working fine. In the app, I've
got a master object called MyApp which has a fair number of properties,
child classes etc. I find it easier to do this:

Dim MyApp As New Beer.App
Session("App") = MyApp

And then do all programming against MyApp, e.g. MyApp.Property1 = SomeValue.
Means that I can work against pure objects and not the session deep in the
business layers.

Works a treat with InProc but my host (WebHost4Life) is starting to annoy by
a) setting the idle timer on the application to just 20 minutes or b)
reducing it down even more when they feel like it the result of which is
that the application shuts down sometimes as little as 5 minutes after the
last request which means the user session also gets discarded so all their
current session settings get lost.

WebHost4Life have suggested looking at StateServer as they support that. I
understand how this works, i.e. the session state is serialised into a
binary stream and stored in a separate process.

My question is *when* does this happen. I suspect it's *not* everytime you
write to Session but at some other point in the page lifecycle. Consider:

Dim Person1 As New Beer.Person
Person1.Name = "Rob"
Session("Person") = Person1
Person1.Name = "Fred"
Dim Person2 As Beer.Person = Session("Person")
Label.Text = Person2.Name

This displays "Fred" on the screen so I'm assuming that Session("Person") is
simply setting up the usual name/value pair with a reference to Person1 and
that:

Dim Person2 As Beer.Person = Session("Person")

Is getting the same reference to Person1 back out of the Session.

So I assume the serialisation occurs at some later stage?

Cheers, Rob.

[Patrice]

It makes sense to do that at the beginning/end of each request plus the
documentation is generally much better than sometimes reported and should
IMO always be searched
(http://www.google.com/search?hl=en&q...=Google+Search
and this is the second entry) before posting.

From http://msdn.microsoft.com/en-us/libr...83(VS.71).aspx :

Instead of keeping live objects, the .NET State Server simply stores session
state in memory when in out-of-proc mode. In this mode the worker process
talks directly to the State Server. In SQL mode, session states are stored
in a SQL Server database and the worker process talks directly to SQL. The
ASP.NET worker processes are then able to take advantage of this simple
storage service by serializing and saving (using .NET serialization
services) all objects within a client's Session collection at the end of
each Web request. When the client revisits the server, the relevant ASP.NET
worker process retrieves these objects from the State Server as binary
streams, deserializes them into live instances, and places them back into a
new Session collection object exposed to the request handler.
--
Patrice

[=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=]

there are three relevent events events in the request life cycle.

AcquireRequestState - load session
ProcessRequest - page life cycle
ReleaseRequestState - save session
-- bruce (sqlwork.com)
"Rob Nicholson" wrote:

I'm currently using InProc session which are working fine. In the app, I've
got a master object called MyApp which has a fair number of properties,
child classes etc. I find it easier to do this:

Dim MyApp As New Beer.App
Session("App") = MyApp

And then do all programming against MyApp, e.g. MyApp.Property1 = SomeValue.
Means that I can work against pure objects and not the session deep in the
business layers.

Works a treat with InProc but my host (WebHost4Life) is starting to annoy by
a) setting the idle timer on the application to just 20 minutes or b)
reducing it down even more when they feel like it the result of which is
that the application shuts down sometimes as little as 5 minutes after the
last request which means the user session also gets discarded so all their
current session settings get lost.

WebHost4Life have suggested looking at StateServer as they support that. I
understand how this works, i.e. the session state is serialised into a
binary stream and stored in a separate process.

My question is *when* does this happen. I suspect it's *not* everytime you
write to Session but at some other point in the page lifecycle. Consider:

Dim Person1 As New Beer.Person
Person1.Name = "Rob"
Session("Person") = Person1
Person1.Name = "Fred"
Dim Person2 As Beer.Person = Session("Person")
Label.Text = Person2.Name

This displays "Fred" on the screen so I'm assuming that Session("Person") is
simply setting up the usual name/value pair with a reference to Person1 and
that:

Dim Person2 As Beer.Person = Session("Person")

Is getting the same reference to Person1 back out of the Session.

So I assume the serialisation occurs at some later stage?

Cheers, Rob.

[Rob Nicholson]

services) all objects within a client's Session collection at the end of

each Web request. When the client revisits the server, the relevant
ASP.NET worker process retrieves these objects from the State Server as
binary streams, deserializes them into live instances, and places them
back into a new Session collection object exposed to the request handler.

Thanks for that - despite me rushing when writing the original post which on
re-reading wasn't too clear. This is what I suspected/hoped happened - the
session is only serialised once at the start/end of the request which means
that you can work in the same way as inproc in terms of the objects you've
placed in the session.

Cheers, Rob.