|
Prev: dropdown list in gridview does not seem to display correct dat
Next: Creating a table cell and changing the color on hover.
From: Rob Nicholson on 3 Jul 2008 12:15 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.
From: Patrice on 3 Jul 2008 12:42 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=state+server+request+site%3Amsdn.microsoft.com&btnG=Google+Search and this is the second entry) before posting. From http://msdn.microsoft.com/en-us/library/87069683(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
From: bruce barker on 3 Jul 2008 14:16 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. > > >
From: Rob Nicholson on 3 Jul 2008 19:22
> 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. |