Asp.net Session Data Loss

Question

I talked about this in a previous question, but since then I narrowed down this question to provide an opportunity to get an answer. Firstly, some background.

I have an ASP.net website that works fine on a local server, but when it is on a real server and accessible from outside, it has some problems with the session data, which sometimes cause errors. The first question turned out to be a problem with IE9. The session variable simply did not persist after it reached the second page and hit the stored procedure. I fixed this by indicating that the page starts in IE7 mode with

This still happens in some browsers (in particular, it happens -once- with firefox), but I created a loop that forces it to return to the menu page when the session variable is empty, so it just appears when the page does not load and the " open "can be pressed again.

However, a new problem occurs when I try to save data in a form. It passes several session variables to the stored procedure interface (for example, personnel identifier, etc.), and it appears that it expires. However, all the timeouts for the session defined in webconfig and IIS are extremely large (many hours), and the workflows are configured so that they never end or are not processed. In addition, this happens even after a minute or two, so there can be no timeout. This is exactly the same as randomly losing session values. The strange thing is that if you go back and save again - doing the same things with the same data - it works. It sometimes takes a few iterations, but it will eventually work.

The strange thing also is that it tends to randomly lose parts of the viewstate - such as field values, but it can be unrelated and have more to do with fields that are automatically populated when loading. But I thought that I would include this in case he offers, and information on why this can be done.

I am considering a workaround by dumping session variables into viewstate variables as soon as the page loads, but I really would like to address the problem directly, so I won’t have to deal with it in the future when I cannot do this. Is there some kind of poriton IIS (by the way, this is IIS 6) that could be the culprit? Are there session variables known only for dying when thrown around? I can’t say that I know a lot about server setup, but I learned a lot from this situation, and beating it will be a great victory for my fighting spirit. Thanks for reading and wish it took so long!

Answer 1

This time I found a real solution. It still doesn't make much sense, but I thought I would bring it here only for everyone. It turns out that one of the dates that were pulled out of the table was stored in the session variable as empty (although it should not have been), and then somehow, even if there was an if statement that should have prevented it, it tried to convert an empty string session date. Of course, strange. It was as if the session mattered when the if statement was reached, and then after she checked it against the criteria, it changed it to an empty string and threw an error.

So, it turns out that this is not a session problem, but just a strange date problem. This happened with only one person and one specific date from the table. I fixed this by simply placing a test lie around me. Since then, everything works great for this person. Thanks again for helping everyone!

Answer 2

Check if this server is balanced.

In any case, check out this article. http://aspalliance.com/1182_Troubleshooting_Session_Related_Issues_in_ASPNET

Hope this helps.

Answer 3

OK!

After reading the message and thinking about it, I think that the most likely cause of the problem is the dodgy ISA server . Proxies, as a rule, deal with HTTP content, decide to change headers, etc. As you already mentioned, this only happens if it is accessed from the outside. This is a sign of a person in average problems.

Now, to prove, you need to compare the headers sent from the outside and the headers you receive. It is a little difficult, but not impossible. All you need to do is register all the headers (requests) on the server side while you do the same from the client machine (possibly with the help of a violinist).

This should be able to prove a dodgy proxy - we have a similar problem in our company.

Answer 4

Well, I did a couple of things and now it works, but I did not test what the actual solution was, and none of them, best of my understanding, should really fix the problem. First of all, at some point I increased the available workflows to three from one, which, as I thought, would allow the user to run several processes on the server on the server, if necessary, but it turns out that this is necessary only for server farms. So I put it on one. This was before when this problem occurred, and I basically just expanded to figure out what to fix.

The second thing I did was to add a simple if statement (if the session variable is empty) in one private element that contains an interface for the stored procedure that sends the session variable. I thought this would be a workaround, but then I looked at my old error logs, and even the stored procedure interface did not raise an error. I have no idea why this could fix the problem at all.

I also created some PerfLogs, like on this page, which Rahul linked to me to try to control what happens with the sessions.

Now, in addition to the odd fact that something inside these attempts (along with any other minor things that I did) did fix the problem, the fact that it never happened on the spot started from the very beginning. I'm not quite sure what happened, but now it works, and I'm not going to imitate it too deeply, because I have many projects that need to be visited. In my opinion, this is most likely a problem with ISA servers that may arise in the future, but my lack of knowledge about their settings limited me to the fact that I actually got there and looked around. When I asked about this, I was told that this should allow everything I need to send through it, to go through it. Despite this, I am just happy that I can move on and work. Hope all this helps some people in a similar situation! Thank you all for your help!