Question

I’ve found articles that describe issues similar to mine but not close enough. I have a really intermittent problem where one user can land on another users session and end up seeing some of their information that’s stored in a session. Here’s my scenario: We use AbleCommerce in a load balanced environment using Application Request Routing and Web Farm Framework. We use in-proc sessions but we have sticky sessions (client/server affinity) configured and working. I’ve verified there is no caching causing this issue (nothing using page output cache, no ARR caching, no IIS or WAAS caching). The information stored in the session that very occasionally ends up on someone elses browser is stored in the session via a session based singleton object.

For Example:

public class ExampleObject
{
    public string ExampleData{get; set;}

    public static TicketingSession Instance
    {
        get
        {
            if (HttpContext.Current.Session["ExampleObject"] == null)
            {
                HttpContext.Current.Session["ExampleObject"] = new ExampleObject();
            }
            return (ExampleObject)HttpContext.Current.Session["ExampleObject"];
        }
    }
}

And then in some other code I can use this:

ExampleObject.Instance.ExampleData = "whatever";
//or
txtSomeTextBox.Text = ExampleObject.Instance.ExampleData;

I know I should steer clear of static data and in-proc sessions in load balanced environments but since I’m using client/server affinity and since this static object I’m using is just a property whos getter simply returns the object directly from the session state I don’t see an issue.

Answer 1

You need to move away from inproc session when in a web farming scenario. You need to use an out of process session store to ensure the Session ID is unique.

ASP.NET stores its Session ID in the browser’s cookie collection. If the users have the same Session ID their sessions will appear the same to the server. Using separate servers, or even worker processes on the same server, can result in these types of Session ID collisions.

You can get more detail via MSDN on various Session-State modes supported by ASP.NET.