Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

8.2. Session Data Partitioning

Another question that frequently arises is around data partitioning of session data between applications. From time to time, someone will have a panic attack because, at first glance, session state looks as if it would leak data from one application into another. Especially in the case of out-of-process session state, where all servers and all applications share a central database (or session server), it is understandable why some developers are a bit leery about accidental data sharing.

The example here starts with the simpler case of in-process session state. When using the in-process mode of operation (ASP.NET 3.5 is really an in-process session state provider, because session state is a provider-based feature as well), the data storage mechanism that is used is the ASP.NET Cache object. Because the Cache object manages a chunk of memory inside an application domain, you automatically gain the benefit of partitioning. There is no remoting capability built into either the Cache object or the in-process session state provider.

As a result, short of attaching a debugger or using Win32 APIs to poke around in memory, there isn't any way that application A's session state can accidentally show up inside of application B. Each ASP.NET application on the web server lives in its own application domain, and there is no mechanism to reach out and access session data across application domains. Of course, nothing prevents you from writing some cross-appdomain ...