Hello, I understand that all InProc session data is always gone when its w3wp owner process recycles as it only resides in the w3wp memory.
I wondered though if it is possible to cache the session data when recycling happens somewhere external to the process, and then reinject (and rebuild) the session when it comes back up. That way I'd get the speed of InProc with the reliability of state server-like externalization when necessary. Is this possible?
Maybe you can store enough information in a cookie (or in ViewState) so that you can re-create a session based on that data in the case the worker process was recycled.
Or you could create your own state server (e.g. a windows service) where you store part of your session, and access this service from the web app via remoting or similar.
You should use the SQL Server for Session State if that's your intention. What you want are sessions that can recover from a complete ending of the host processs. Neither inproc or stateserver support that as once they go down they lose all data. You could write your own state method, but that would be laboriuous. Here's directions if you want to do that:
What you may want to do is not use sessions at all, but rather rely more on ViewState. If you have a high traffic site that's a good way to push the workload off to clients.
No, this isn't possible. There is no API to "warm up" in-process session state or cache. Such a solution would be unreliable anyway. You couldn't gaurantee that the last thing your app did would be to export its current session state, so you could never count on the imported data to be current anyway.
You can use the out-of-proc state server on the same host as your web application. Then the web application can recycle freely, keeping the state information intact. This is quite a bit faster than using SQL Server to manage sessions, as you don't have to deal with the overhead of SQL or network transit to another machine, the only way it's worse than in-process session state is that data has to marshal across process boundaries, but as long as you don't have a massive amount of rapidly changing session data, this shouldn't be noticeable at all.
There are also other alternatives, such as Microsoft Project Code Named "Velocity" or ScaleOut Software's SessionServer (among others I'm sure) that offer distributed caching mechanisms that can keep session state or cache synchronized between servers in a server farm without having to resort to using SQL Server.
Contrary to what another user posted, I would NOT use ViewState to store session data if at all possible. For one, it's not true session state, if a user moves back or forward it can be lost. Second, it's fairly insecure. Third, it causes massive page bloat if abused.