1

We have a ASP.net form [.NET 3.5 on IIS 6] that loads controls dynamically. We are able to retain the values in the viewstate as long as the postback happens within 20 minutes. The database also gets updated properly. Everything works as expected.

However, If it takes more than 20 minutes for a user to fill out the form, the controls no longer retain their values during postbacks. The session values are intact, the user authentication is also intact. We tried several things

1) Added machine keys to web.config files - we have 2 web servers load balanced by Windows load balancer

2) We confirmed that the user are routed to the same server – because the sessions are sticky

3) Increased the session timeout to 60 minutes in IIS 6.0

4) Increased the Idle timeout for connection pool to 60 minutes

5) Changed Form authentication ticket timeout to 60 minutes

Any help would be appreciated.

-Thanks

Rajesh
  • 11
  • 1
  • What exactly do you mean by "the controls no longer retain their values during postback"? If you have a form with a button and a textbox, fill in the textbox and hit the button after 20 minutes, the textbox.text property will be empty on the server? – Greg Dec 03 '10 at 18:24
  • Yes - when I try to update the database with the values entered in the control - they are all empty. – Rajesh Dec 06 '10 at 21:21

3 Answers3

4

20 minutes is the default timeout for application pool recycling. Run IIS Manager on the server, go into the Application Pool properties, and unclick 'Recycle worker processes (in minutes)', or set it to 60.

Patrick McDonald
  • 64,141
  • 14
  • 108
  • 120
1

"sticky" sessions do not mean "always go to same server". It is just a suggestion. Granted, a strong one, but still just a suggestion. The load balancer works by keeping an in memory cache of clients and their destination server. This memory is limited and is garbage collected on a regular basis. Meaning, you might very well be bouncing between servers based on the amount of time between requests.

If you are using in memory session data with load balanced machines, then you have to either 1. stop using session or change the backing store to be a session state server or sql server. This is the only way to be sure that the session data is actually available across all target servers.

How did you determine that the session and user values were still intact? Are you just guessing like you are about which server they are going to?

To completely eliminate load balancing as a culprit, turn off all but one of the machines.

NotMe
  • 87,343
  • 27
  • 171
  • 245
0

Problem can be in <sessionPageState historySize="9" /> configuration. It control's how many "postback results" are stored in Session. Each postback records it's ViewState to the end of the Queue in Session["__VIEWSTATEQUEUE"].

AareP
  • 2,355
  • 3
  • 21
  • 28