Ignore it, it will go away.

Like a child saying they are hungry, most things can be ignored and the problem will just solve itself. This isn't always the case in IT. Oh sure, you have problems that seem to just go away. But what caused it in the first place?

Let's look at a common problem in the .NET world. Session. Session is a great tool you can use to store information your app needs to run without a cookie. The other cool thing is that sessions have a short time span of the users session, or when you say die.

Now you must be thinking, wow what could go wrong with this setup? Well session works great until you have to deal with a couple stumbling blocks, that are very very common.

Sessions have a built in timer to die set by the server but can be overridden by the application. So you could just set it to something ridiculously high like a day, but something has to store that on your server, and it is usually in memory, so that won't last very long with a busy app.(there are other ways, we will cover them below) So you set it to 20 minutes and hope for the best? The best solution that you can try is to have a timer on the page with a need more time button, but somebody will still miss that.

So your application starts to get more popular. You need to add in a few more servers and load balancing. You are set to expand right? No changes needed, well, of course that is if your user never leaves your application for any reason. So here is the scenario, you application needs to send a customer to another application, like a commonly used checkout page to keep you out of the business of worrying about PCI. What happens when you come back to your application? .Well I can tell you, session will break. Chances are you won't land on the exact same server that you left from. Then your session won't have a clue what to do, as well as any cookies will de-serialize wrong. So how do you solve this? There are a few ways, and they all work about the same, just depending on your resources you have.

So let's start with the most simple. If you have load balancing set up, then you can tell the load balancing tool to use something called Session Affinity. What this does is stores a cookie in the users browser. This cookie is read by the load balancer to let it know what server it came from, and puts it back into the right location. This is usually the simplest of solutions, well for me. Although this isn't fool proof. A user might delete their cookies, or worse not allow them. So now what?

Well session can be stored in multiple ways; in memory, on another server, or a sql server.

In memory is the most basic. No complicated set up, no need to get routes set up or permissions. Your application pool just stores that information. The problem though is that if you do any maintenance that bounces your applications app pool, well all open session just got killed. So easiest, just not the most efficient. Makes deploys tricky.

You can just point to another server and have it store your session. I have done this before, and it also works very easily. Just a simple web.config change and you are set up. The problem is that you must make sure that you have routes set up.

Now the best way to do this, but takes the most set up, is storing sessions in SQL server. You can set up a session state server using SQL server. Every time that a session is opened up, it gets placed in the database. This is nice, because then you can truly have a load balanced application environment  No longer to you need to worry about what server your users come back to. The application will always go find the user in session state server and you're good to go.

So this was a lot to just tell my fun story from last week.

Logs are showing that we have invalid and empty sessions all over our application. Well shit, we have got to track down the root of this problem. Well we thought we had session affinity turned on. Maybe not? So we turned off one of our web tiers. Still we are seeing issues in the logs. Great, well now we just gave ourselves a limp, and still have cancer. Start doing a little digging and figure out that all the session are dying in the same place. Before they leave the application they have to upload a document to the application. Well, if it takes more than 20 minutes....session is killed and no warning is given to the customer. There is your problem right there. 

Something that when I saw it in the logs, we can choose to ignore this, but we need to fix it. A timer will soon be going up as well as the 'I need more time' button. Just more fun times in a long month that I never thought would end.